Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
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] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Читать заметки Дмитрия Пилюгина |
||
31 окт 17, 18:19 [20916888] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Vadim Romanenko, Ну и 2 ключевых вывода. Первый - "Это ведет к очень важному выводу: значения параметров при первом вызове процедуры, имеют огромное влияние на последующие вызовы. Если первый набор значений по каким-либо причинам оказывается нетипичным, то план, сохраненный в кэш, может оказаться не эффективным для последующих выполнений. Вот почему прослушивание параметров такая важная часть." Второй - "В кэше планов выполнения есть план для хранимой процедуры. Значит ли это, что его будут использовать все? Нет, в этой части мы узнаем, что для одной и той же процедуры может быть несколько планов выполнения." |
31 окт 17, 18:21 [20916899] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
Vadim Romanenko, вывод SELECT @@OPTIONSможете вставить куданибудь в вызов из приложения ASP.Net или что проще снимите трассу по событию ShowPlan Statistics Profile для обоих сессий |
31 окт 17, 18:23 [20916908] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
Я вроде ж написал пункт: "- статья "Медленно в приложении, быстро в SSMS" не помогла - выставление ARITHABORT не приводит к ускорению в рантайме, точно так же - снятие галки не приводит к замедлению при выполнении из SSMS" Со статьей знаком - она не помогла. Как минимум по двум причинам: а) выставление параметра, который он винит во всех бедах - не привело ни к увеличению скорости из приложения, ни к замедлению скорости в SSMS б) вызов процедуры происходил с одним и тем же значением единственного параметра |
31 окт 17, 18:24 [20916911] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
Vadim Romanenko, и сразу в догонку ExistingConnection класс что бы было видно поле BinaryData |
31 окт 17, 18:32 [20916936] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
OPTIONS: 5946 Одинаковый как для приложения, так и для SSMS Тупик
Живчик
|
||
31 окт 17, 18:34 [20916942] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Делали DBCC FREEPROCCACHE, а потом проверку из ASP.NET и SSMS? |
||
31 окт 17, 18:38 [20916958] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Вот это внутри процедуры - использование параметра. 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] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
Andy_OLAP, та же картина с подменой на локальную переменную. Но я так понял - эта подмена как раз и запутывает оптимизатор. В любом случае - заведение дополнительного локального параметра-дубликата не ускорило выполнение процедуры. |
31 окт 17, 18:48 [20917004] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
Может быть что-то не так с определением индекса? Я честно говоря не силен в физических параметрах определения таблиц и ключей. Отмечу только, что кластера у нас нет, не было и не будет. Не в курсе, что означает кластеризованный индекс в SQL Server. Или может ли так получиться, что индекс битый? И оно глушит системные ошибки где-то глубоко внутри себя... Хотя - это не объясняет, почему процедура отрабатывает быстро из SSMS и тупит через приложение |
31 окт 17, 18:51 [20917015] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
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] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
Только что в качестве тесТест - заменил упомянутую таблицу на другую - отработало быстро. Т.е. проблема где-то в этой таблице и ее индексах, КМК. |
31 окт 17, 18:56 [20917039] Ответить | Цитировать Сообщить модератору |
andreymx Member Откуда: Запорожье Сообщений: 54894 |
|
||
31 окт 17, 19:00 [20917055] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
Пожалуйста Тупик: 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] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
andreymx, пересобрал еще раз вручную средствами SSMS. Не помогло. Если у Вас есть средство проверить - подскажите, я проверю еще раз |
31 окт 17, 19:06 [20917081] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Попробуйте в SSMS закрыть соединение с сервером и заново открыть его с явным указанием протокола TCP в Options. И еще раз проверьте запрос. |
||||
31 окт 17, 19:07 [20917087] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
Vadim Romanenko, ну мои предположения в целом закончились :) У вас там хост на котором asp приложение не на Камчатке случаем? Есть еще вариант посмотреть в sys.dm_os_waiting_tasks по session_id после прошествия 10 секунд для сессии asp.net приложения, нет ли там случаем ASYNC_NETWORK_IO? |
31 окт 17, 19:11 [20917106] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Вы кэш сбрасывали? DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE. Затем измерить СНАЧАЛА из SSMS, затем из Web Service. Потом снова DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE. Затем измерить СНАЧАЛА из Web Service, затем из SSMS. Результаты сюда. |
||
31 окт 17, 19:13 [20917114] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
Andy_OLAP, вы забыли написать
если это тестовый сервер, а на рабочем эти команды не используйте, иначе узнаете много хорошего о себе. |
||
31 окт 17, 19:16 [20917125] Ответить | Цитировать Сообщить модератору |
Vadim Romanenko Member Откуда: Харьков, Украина Сообщений: 1462 |
Я попробовал добавить эту информацию, но объем данных лавинообразный. Подскажите пожалуйста, какие фильтры нужно применить, чтоб получить интересующую Вас информацию? В данный момент у меня несколько десятков тысяч (как мне кажется) строк в профайлере |
||
31 окт 17, 19:18 [20917135] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Если метод не работает - его нужно отлаживать на тестовом сервер и на тестовой базе, копии боевой, куда никто кроме ASP.NET не лезет. Я думал, такое разжевывать автору темы вряд ли нужно. |
||||
31 окт 17, 19:22 [20917150] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |