Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
Привет всем!

Сложилась забавная ситуация. При вызове запроса из ASP.NET Web Service метода - запрос выполняется 30 секунд (по статистике профайлера). Снимаю текст вызова в SQL Server Profiler. Выполняю его же из SQL Server Management Studio. Время выполнения меньше секунды. При повторном выполнении операции - та же картина. Из сервиса - 30 секунд, из студии - меньше секунды.
Не представляю с какой стороны подобраться к решению проблемы. Может кто-то подсказать?
К сообщению приложено два скрина из профайлера

Скрин 1 - 30 секунд
Картинка с другого сайта.

Скрин 2 - меньше секунды
Картинка с другого сайта.

По совету камрадов из соседней ветки сделано следующее:
- копия БД перенесена на рабочий компьютер через экспорт-импорт - проблема осталась
- ребилд индексов и сбор статистики не помог (хотя может у кого есть проверенные скрипты? Возможно, я выбрал не тоРт)
- сброшена статистика по хранимой процедуре - не помогло
- при выполнении запроса из Visual Studio код отрабатывает так же быстро, как и из SSMS, с использованием sp_executesql
- снял explain plan при выполнении из SSMS и при выполнении из запущенного приложения - количество чтений и нагрузка на CPU практически одинаковые, время выполнения - 16 против 29909 (мс)
- статья "Медленно в приложении, быстро в SSMS" не помогла - выставление ARITHABORT не приводит к ускорению в рантайме, точно так же - снятие галки не приводит к замедлению при выполнении из SSMS

Вобщем, если у кого есть какие идеи куда копать - буду чеГтовски благодарен
31 окт 17, 18:06    [20916843]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko
Привет всем!

Сложилась забавная ситуация. При вызове запроса из ASP.NET Web Service метода - запрос выполняется 30 секунд (по статистике профайлера). Снимаю текст вызова в SQL Server Profiler. Выполняю его же из SQL Server Management Studio. Время выполнения меньше секунды. При повторном выполнении операции - та же картина. Из сервиса - 30 секунд, из студии - меньше секунды.
Не представляю с какой стороны подобраться к решению проблемы. Может кто-то подсказать?
К сообщению приложено два скрина из профайлера

Скрин 1 - 30 секунд
Картинка с другого сайта.

Скрин 2 - меньше секунды
Картинка с другого сайта.

По совету камрадов из соседней ветки сделано следующее:
- копия БД перенесена на рабочий компьютер через экспорт-импорт - проблема осталась
- ребилд индексов и сбор статистики не помог (хотя может у кого есть проверенные скрипты? Возможно, я выбрал не тоРт)
- сброшена статистика по хранимой процедуре - не помогло
- при выполнении запроса из Visual Studio код отрабатывает так же быстро, как и из SSMS, с использованием sp_executesql
- снял explain plan при выполнении из SSMS и при выполнении из запущенного приложения - количество чтений и нагрузка на CPU практически одинаковые, время выполнения - 16 против 29909 (мс)
- статья "Медленно в приложении, быстро в SSMS" не помогла - выставление ARITHABORT не приводит к ускорению в рантайме, точно так же - снятие галки не приводит к замедлению при выполнении из SSMS

Вобщем, если у кого есть какие идеи куда копать - буду чеГтовски благодарен

Читать заметки Дмитрия Пилюгина
31 окт 17, 18:19    [20916888]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko,

Ну и 2 ключевых вывода.
Первый - "Это ведет к очень важному выводу: значения параметров при первом вызове процедуры, имеют огромное влияние на последующие вызовы. Если первый набор значений по каким-либо причинам оказывается нетипичным, то план, сохраненный в кэш, может оказаться не эффективным для последующих выполнений. Вот почему прослушивание параметров такая важная часть."
Второй - "В кэше планов выполнения есть план для хранимой процедуры. Значит ли это, что его будут использовать все? Нет, в этой части мы узнаем, что для одной и той же процедуры может быть несколько планов выполнения."
31 окт 17, 18:21    [20916899]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1364
Vadim Romanenko,

вывод
SELECT @@OPTIONS 
можете вставить куданибудь в вызов из приложения ASP.Net

или что проще снимите трассу по событию ShowPlan Statistics Profile для обоих сессий
31 окт 17, 18:23    [20916908]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
Я вроде ж написал пункт:
"- статья "Медленно в приложении, быстро в SSMS" не помогла - выставление ARITHABORT не приводит к ускорению в рантайме, точно так же - снятие галки не приводит к замедлению при выполнении из SSMS"

Со статьей знаком - она не помогла. Как минимум по двум причинам:
а) выставление параметра, который он винит во всех бедах - не привело ни к увеличению скорости из приложения, ни к замедлению скорости в SSMS
б) вызов процедуры происходил с одним и тем же значением единственного параметра
31 окт 17, 18:24    [20916911]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1364
Vadim Romanenko,

и сразу в догонку ExistingConnection класс что бы было видно поле BinaryData
31 окт 17, 18:32    [20916936]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
felix_ff
Vadim Romanenko,

вывод
SELECT @@OPTIONS 
можете вставить куданибудь в вызов из приложения ASP.Net

или что проще снимите трассу по событию ShowPlan Statistics Profile для обоих сессий


OPTIONS: 5946
Одинаковый как для приложения, так и для SSMS

Тупик

Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
---- -------- -------- ------ ------ ------ ---------- --------- -------- ------------- ------------ ---------- ----------- ---------- ---------------- ---------- -------- ---- -------- ------------------
1 1 Clustered Index Seek(OBJECT:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_tbAppLegs]), SEEK:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_id]=[@legId]) ORDERED FORWARD) 0 0 Clustered Index Seek Clustered Index Seek OBJECT:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_tbAppLegs]), SEEK:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_id]=[@legId]) ORDERED FORWARD [AmbuletteQueue_Office].[dbo].[tbAppLegs].[appId] 1 0.003125 0.0001581 11 0.0032831 [AmbuletteQueue_Office].[dbo].[tbAppLegs].[appId] PLAN_ROW 0 1



Живчик

Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
---- -------- -------- ------ ------ ------ ---------- --------- -------- ------------- ------------ ---------- ----------- ---------- ---------------- ---------- -------- ---- -------- ------------------
1 1 Clustered Index Seek(OBJECT:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_tbAppLegs]), SEEK:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_id]=[@legId]) ORDERED FORWARD) 0 0 Clustered Index Seek Clustered Index Seek OBJECT:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_tbAppLegs]), SEEK:([AmbuletteQueue_Office].[dbo].[tbAppLegs].[pk_id]=[@legId]) ORDERED FORWARD [AmbuletteQueue_Office].[dbo].[tbAppLegs].[appId] 1 0.003125 0.0001581 11 0.0032831 [AmbuletteQueue_Office].[dbo].[tbAppLegs].[appId] PLAN_ROW 0 1
31 окт 17, 18:34    [20916942]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
А, пардоньте, забыл написать - отвечая на уточняющие вопросы. По
Обнаружил, что проблема возникает даже если оставить в ХП простейший запрос к таблице вот такого вида:
	select @appID = appId
	  from tbAppLegs 
	 where pk_id = @legId


Т.е. запрос по значению первичного ключа. Определение первичного ключа:
ALTER TABLE [dbo].[tbAppLegs] ADD  CONSTRAINT [pk_tbAppLegs] PRIMARY KEY CLUSTERED 
(
	[pk_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90)


"ключ не мой, я просто разместил объяву" (с) :)

На данный момент ХП урезана до вот этого единственного запроса, после него идет return. При этом - характер выполнения ХП полностью соответствует тому, что объявлено в стартпосте.
31 окт 17, 18:38    [20916955]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko
Я вроде ж написал пункт:
"- статья "Медленно в приложении, быстро в SSMS" не помогла - выставление ARITHABORT не приводит к ускорению в рантайме, точно так же - снятие галки не приводит к замедлению при выполнении из SSMS"

Со статьей знаком - она не помогла. Как минимум по двум причинам:
а) выставление параметра, который он винит во всех бедах - не привело ни к увеличению скорости из приложения, ни к замедлению скорости в SSMS
б) вызов процедуры происходил с одним и тем же значением единственного параметра

Делали DBCC FREEPROCCACHE, а потом проверку из ASP.NET и SSMS?
31 окт 17, 18:38    [20916958]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko
А, пардоньте, забыл написать - отвечая на уточняющие вопросы. По
Обнаружил, что проблема возникает даже если оставить в ХП простейший запрос к таблице вот такого вида:
	select @appID = appId
	  from tbAppLegs 
	 where pk_id = @legId


Т.е. запрос по значению первичного ключа. Определение первичного ключа:
ALTER TABLE [dbo].[tbAppLegs] ADD  CONSTRAINT [pk_tbAppLegs] PRIMARY KEY CLUSTERED 
(
	[pk_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90)


"ключ не мой, я просто разместил объяву" (с) :)

На данный момент ХП урезана до вот этого единственного запроса, после него идет return. При этом - характер выполнения ХП полностью соответствует тому, что объявлено в стартпосте.

Вот это внутри процедуры - использование параметра.
select @appID = appId
from tbAppLegs
where pk_id = @legId
А вот это - использование плана с локальной переменной, которая меняется на параметр при вызове. Попробуйте.
declare @local_legId bigint
set @local_legId = @legId
select @appID = appId
from tbAppLegs
where pk_id = @local_legId
31 окт 17, 18:40    [20916963]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
Andy_OLAP,

та же картина с подменой на локальную переменную. Но я так понял - эта подмена как раз и запутывает оптимизатор.
В любом случае - заведение дополнительного локального параметра-дубликата не ускорило выполнение процедуры.
31 окт 17, 18:48    [20917004]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
Может быть что-то не так с определением индекса? Я честно говоря не силен в физических параметрах определения таблиц и ключей. Отмечу только, что кластера у нас нет, не было и не будет. Не в курсе, что означает кластеризованный индекс в SQL Server.

Или может ли так получиться, что индекс битый? И оно глушит системные ошибки где-то глубоко внутри себя... Хотя - это не объясняет, почему процедура отрабатывает быстро из SSMS и тупит через приложение
31 окт 17, 18:51    [20917015]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1364
Vadim Romanenko,

оно и не должно было никак ускорить, а наоборот замедлить.

У вас план идентичный для обоих вызовов. ок, включите в трассу события класса Scans =>Started, Stoped с временем выполнения, и Locks:Accuried, Released, Timeout

где то явно должно быть различие.
И если можно еще проверьте для обоих сессий
select net_packet_size, net_transport, protocol_type, protocol_version from sys.dm_exec_connections where session_id in (<spid1>, <spid2>)
31 окт 17, 18:55    [20917033]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
Только что в качестве тесТест - заменил упомянутую таблицу на другую - отработало быстро. Т.е. проблема где-то в этой таблице и ее индексах, КМК.
31 окт 17, 18:56    [20917039]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54167
Vadim Romanenko
Только что в качестве тесТест - заменил упомянутую таблицу на другую - отработало быстро. Т.е. проблема где-то в этой таблице и ее индексах, КМК.
по этой таблице статистика точно актуальна?
31 окт 17, 19:00    [20917055]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
felix_ff
Vadim Romanenko,

оно и не должно было никак ускорить, а наоборот замедлить.

У вас план идентичный для обоих вызовов. ок, включите в трассу события класса Scans =>Started, Stoped с временем выполнения, и Locks:Accuried, Released, Timeout

где то явно должно быть различие.
И если можно еще проверьте для обоих сессий
select net_packet_size, net_transport, protocol_type, protocol_version from sys.dm_exec_connections where session_id in (<spid1>, <spid2>)


Пожалуйста
Тупик:
net_packet_size = 4096, net_transport, protocol_type = TCP, protocol_type = TSQL, protocol_version = 1895825409

Ну и просто из сессии SSMS:
net_packet_size = 4096, net_transport, protocol_type = Shared memory, protocol_type = TSQL, protocol_version = 1946157060
31 окт 17, 19:05    [20917077]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
andreymx,

пересобрал еще раз вручную средствами SSMS. Не помогло. Если у Вас есть средство проверить - подскажите, я проверю еще раз
31 окт 17, 19:06    [20917081]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko
felix_ff
Vadim Romanenko,

оно и не должно было никак ускорить, а наоборот замедлить.

У вас план идентичный для обоих вызовов. ок, включите в трассу события класса Scans =>Started, Stoped с временем выполнения, и Locks:Accuried, Released, Timeout

где то явно должно быть различие.
И если можно еще проверьте для обоих сессий
select net_packet_size, net_transport, protocol_type, protocol_version from sys.dm_exec_connections where session_id in (<spid1>, <spid2>)


Пожалуйста
Тупик:
net_packet_size = 4096, net_transport, protocol_type = TCP, protocol_type = TSQL, protocol_version = 1895825409

Ну и просто из сессии SSMS:
net_packet_size = 4096, net_transport, protocol_type = Shared memory, protocol_type = TSQL, protocol_version = 1946157060

Попробуйте в SSMS закрыть соединение с сервером и заново открыть его с явным указанием протокола TCP в Options. И еще раз проверьте запрос.
31 окт 17, 19:07    [20917087]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
Andy_OLAP,

первый запрос - 1 секунда, повторный - 0 секунд. Открыл новый SSMS для чистоты эксперимента

результат запроса в новом SSMS:

net_packet_size = 4096, net_transport, protocol_type = TCP, protocol_type = TSQL, protocol_version = 1946157060
31 окт 17, 19:10    [20917097]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1364
Vadim Romanenko,

ну мои предположения в целом закончились :)

У вас там хост на котором asp приложение не на Камчатке случаем?
Есть еще вариант посмотреть в sys.dm_os_waiting_tasks по session_id после прошествия 10 секунд для сессии asp.net приложения, нет ли там случаем ASYNC_NETWORK_IO?
31 окт 17, 19:11    [20917106]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko
andreymx,

пересобрал еще раз вручную средствами SSMS. Не помогло. Если у Вас есть средство проверить - подскажите, я проверю еще раз

Вы кэш сбрасывали?

DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE.
Затем измерить СНАЧАЛА из SSMS, затем из Web Service.

Потом снова DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE.
Затем измерить СНАЧАЛА из Web Service, затем из SSMS.

Результаты сюда.
31 окт 17, 19:13    [20917114]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1364
Andy_OLAP,

вы забыли написать

DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE.
Затем измерить СНАЧАЛА из SSMS, затем из Web Service.

Потом снова DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE.
Затем измерить СНАЧАЛА из Web Service, затем из SSMS.

если это тестовый сервер, а на рабочем эти команды не используйте, иначе узнаете много хорошего о себе.
31 окт 17, 19:16    [20917125]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Vadim Romanenko
Member

Откуда: Харьков, Украина
Сообщений: 1462
felix_ff
Vadim Romanenko,
У вас план идентичный для обоих вызовов. ок, включите в трассу события класса Scans =>Started, Stoped с временем выполнения, и Locks:Accuried, Released, Timeout

[/src]

Я попробовал добавить эту информацию, но объем данных лавинообразный. Подскажите пожалуйста, какие фильтры нужно применить, чтоб получить интересующую Вас информацию? В данный момент у меня несколько десятков тысяч (как мне кажется) строк в профайлере
31 окт 17, 19:18    [20917135]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Vadim Romanenko,

Что с настройками ASP.NET?
debug=false установлено в web.config?
Что у Вас в методе для TraceContext.IsEnabled - true или false? Вы трассировку внутри вызова не выполняете ли случаем?
А то запрос то выполняется за ту же секунду - только обвязка вокруг идет 30 секунд.
ASP.NET видит SQL напрямую, внутри той же локальной сети, или через кучу маршрутизаторов и прокси типа Apache?
31 окт 17, 19:21    [20917144]     Ответить | Цитировать Сообщить модератору
 Re: Разное время выполнения запроса из C# и SSMS  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
felix_ff
Andy_OLAP,

вы забыли написать

DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE.
Затем измерить СНАЧАЛА из SSMS, затем из Web Service.

Потом снова DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE.
Затем измерить СНАЧАЛА из Web Service, затем из SSMS.

если это тестовый сервер, а на рабочем эти команды не используйте, иначе узнаете много хорошего о себе.

Если метод не работает - его нужно отлаживать на тестовом сервер и на тестовой базе, копии боевой, куда никто кроме ASP.NET не лезет. Я думал, такое разжевывать автору темы вряд ли нужно.
31 окт 17, 19:22    [20917150]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить