Причина медленного выполнения запроса

@kotelok · Регистрация: 08.08.2014

Author24 — интернет-сервис помощи студентам

Есть база на MS SQL Server.

Один и тот же бэкап восстановлен на несколько серверов.

Из Management Studio к базе выполняется сложный запрос, который стабильно отрабатывает примерно за 1 секунду на всех машинах.

И есть простейший код в одном из старых сервисов:

C#

    using (var conn = new SqlConnection("<connection string>"))
    {
        conn.Open();
 
        using (var adapter = new SqlDataAdapter("<sql>", conn))
        {
            var dt = new DataTable();
            adapter.Fill(dt);
        }
    }

Сервис физически запущен на той же машине, где и SQL Server.

И на одном из серверов, вот этот 'adapter.Fill(dt);' по какой-то непонятной причине выполняется 20-40 секунд (замер времени и логирование чисто на этой строке стоит). Хотя если ровно тот же запрос к тому же SQLServer выполнить из ManagementStudio, то он всё так же выполняется примерно за секунду.

Памяти 32ГБ, большая часть свободна. Процессор ничем не занят. Если у SQLServer запросить список текущих сессий/запросов, то там тоже пусто.

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

@Andrey-MSK · 19.11.2024, 11:16

Сообщение от kotelok

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

А что показывает профайлер, тот который в SSMS встроен, во время этого запроса?
И вот это

Сообщение от kotelok

C#

1	conn.Open();

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

@kotelok · 19.11.2024, 14:31 **[ТС]**

Сообщение от Andrey-MSK

А что показывает профайлер

Пока не знаю. Я этот проблемный SQLServer просто перезапустил как сервис (без перезагрузки машины даже). Он всё так же (как до перезагрузки) занимает сейчас около 6ГБ в памяти (ещё 20 на машине свободно), всё так же не потребляет процессор, но при этом время выполнения запроса из SSMS и .net-кода стало одинаковым.

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

Добавлено через 1 час 3 минуты
Andrey-MSK,
В общем, аномалия. Профилировщик показывает, что при запросе из .net-кода, полностью идентичный запрос выполняется раз в 12-16 дольше.

При этом, если из SSMS сделать вызов так же через 'exec sp_executesql' (это не я, это DataAdapter так работает), то всё ок, тоже быстро отрабатывает.

Код

client_app_name         SSMS        .Net Sql Client Data Provider
batch_text              <sql>       -
statement               -           exec sp_executesql n'<sql>'
object_name             -           sp_executesql

----
attach_activity_id.seq          2	     1
cpu_time                1 939 000   28 203 000
duration                1 526 567   28 508 694
event_sequence                601        2 538
logical_reads             839 028    2 111 781
physical_reads	                0            0
query_hash                      0            0
row_count                     759          759
writes                      1 665            0

Добавлено через 54 секунды
P.S.: физически один и тот же сервер, одна и та же база, в обоих случаях подключение к базе из локально запущенного экземпляра приложения.

@Andrey-MSK · 19.11.2024, 14:44

А если вот это

Сообщение от kotelok

batch_text <sql>

засунуть в хранимку (CREATE PROC) и вызывать её через SqlCommand(). По идее сервер должен будет её скомпилировать и сохранить для неё план запроса, и потом всегда использовать его до кардинальных изменений в хранимке...

@kotelok · 19.11.2024, 15:13 **[ТС]**

Andrey-MSK
По результатам случайного поиска сделал вот такое:

T-SQL

1	update statistics [dbo].[<table>] with fullscan;

Сделал только для корневой таблицы запроса (там их, куда более объёмных, ещё десяток в рамках запроса используется).

Где-то полторы минуты заняло.

И после этого запрос стал из .net-приложения выполняться столько же, сколько и из SSMS.

Но понятнее не стало. Ну т.е. я для теста в SSMS даже явным образом прописывал открытие транзакции того же типа, что и в приложении, и вызов делал через 'exec sp_executesql'. Но оно всё равно стабильно быстро работало. Похоже, что при запросе из приложения оно, почему-то, использует какой-то другой, не особо эффективный план запроса. Но, почему-то, не всегда.

@Andrey-MSK · 19.11.2024, 15:18

Сообщение от kotelok

update statistics

Полезная штука, особенно когда идёт интенсивное обновление (запись, обновление, удаление) данных в БД. Перестраивает все индексы и после этого запросы начитают работать гораздо быстрее. Для 1С, где-то читал рекомендации, это нужно делать пару раз в месяц...
На своей БД делаю это после массового залива спецификаций чертежей

@Usaga · 19.11.2024, 15:56

Сообщение от kotelok

var dt = new DataTable();
adapter.Fill(dt);

Зачем? На дворе 2006й год? Используй чистый ADO.NET.

И не надо забывать, что выгребание данных из базы и их материализация тоже время и ресурсы занимает. Особенно, когда этих данных дофига.

@kotelok · 19.11.2024, 15:59 **[ТС]**

Сообщение от Usaga

Зачем? На дворе 2006й год? Используй чистый ADO.NET.

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

Сообщение от Usaga

И не надо забывать, что выгребание данных из базы и их материализация тоже время и ресурсы занимает. Особенно, когда этих данных дофига.

В данном случае проблема на стороне SQL Server. После обозначенных выше странных процедур, он начал корректный план применять в т.ч. и для запросов из приложения.

@Usaga · 19.11.2024, 16:07

Сообщение от kotelok

В данном случае проблема на стороне SQL Server. После обозначенных выше странных процедур, он начал корректный план применять в т.ч. и для запросов из приложения.

Если из приложения вызывается хранимка, то ей можно добавить WITH RECOMPILE. Мы такое в старом сервисе тоже иногда применяли, когда неверный план запроса использовался.

Новые блоги и статьи
UserScript для подсветки кнопок языков программирования в зависимости от текущего раздела volvo 13.01.2025 В результате работы этого скрипта подсвечиваются нужные кнопки не только в форм быстрого ответа, но и при редактировании сообщения: / / ==UserScript== / / @name CF_DefaultLangSelect / / . . .	Введение в модели и алгоритмы машинного обучения InfoMaster 12.01.2025 Машинное обучение представляет собой одну из наиболее динамично развивающихся областей искусственного интеллекта, которая фокусируется на разработке алгоритмов и методов, позволяющих компьютерам. . .	Как на Python создать нейросеть для решения задач InfoMaster 12.01.2025 В контексте стремительного развития современных технологий особое внимание уделяется таким инструментам, как нейросети. Эти структуры, вдохновленные биологическими нейронными сетями, используются для. . .	Как создать нейросеть для генерации картинок на Python InfoMaster 12.01.2025 Генерация изображений с помощью искусственных нейронных сетей стала одним из наиболее захватывающих направлений в области компьютерного зрения и машинного обучения. В этой статье мы рассмотрим. . .	Создание нейросети для генерации текста на Python InfoMaster 12.01.2025 Нейросети, или искусственные нейронные сети, представляют собой модели машинного обучения, вдохновленные работой человеческого мозга. Они состоят из множества взаимосвязанных узлов, или "нейронов",. . .	Как создать нейросеть распознавания изображений на Python InfoMaster 12.01.2025 Введение в распознавание изображений с помощью нейросетей Распознавание изображений с помощью нейронных сетей стало одним из самых впечатляющих достижений в области искусственного интеллекта. Эта. . .
Основы искуственного интеллекта InfoMaster 12.01.2025 Искусственный интеллект (ИИ) представляет собой одну из наиболее динамично развивающихся областей современной науки и технологий. В широком смысле под искусственным интеллектом понимается способность. . .	Python и нейросети InfoMaster 12.01.2025 Искусственные нейронные сети стали неотъемлемой частью современных технологий, революционизировав множество областей - от медицинской диагностики до автономных транспортных средств. Python, благодаря. . .	Python в машинном обучении InfoMaster 12.01.2025 Python стал неотъемлемой частью современного машинного обучения, завоевав позицию ведущего языка программирования в этой области. Его популярность обусловлена несколькими ключевыми факторами, которые. . .	Создание UI на Python с TKinter InfoMaster 12.01.2025 TKinter — это одна из наиболее популярных библиотек для создания графических интерфейсов пользователей (GUI) в языке программирования Python. TKinter входит в стандартную библиотеку Python, что. . .	HTML5 в разработке мобильных приложений InfoMaster 12.01.2025 Введение: Обзор роли HTML5 в мобильной разработке В современном мире мобильных технологий HTML5 стал ключевым инструментом для разработки кроссплатформенных приложений. Эта технология произвела. . .	Как создавать приложения для iOS/iPhone InfoMaster 12.01.2025 Введение в разработку iOS-приложений Разработка приложений для iOS открывает огромные возможности в мире мобильных технологий. С каждым годом количество пользователей iPhone и iPad растет,. . .

@kotelok 1290 / 869 / 258 Регистрация: 08.08.2014 Сообщений: 2,484
	19.11.2024, 14:31 [ТС]	3
	Сообщение от Andrey-MSK А что показывает профайлер Пока не знаю. Я этот проблемный SQLServer просто перезапустил как сервис (без перезагрузки машины даже). Он всё так же (как до перезагрузки) занимает сейчас около 6ГБ в памяти (ещё 20 на машине свободно), всё так же не потребляет процессор, но при этом время выполнения запроса из SSMS и .net-кода стало одинаковым. Теперь надо подождать, когда ему снова сплохеет, чтобы через профайлер посмотреть. Добавлено через 1 час 3 минуты Andrey-MSK, В общем, аномалия. Профилировщик показывает, что при запросе из .net-кода, полностью идентичный запрос выполняется раз в 12-16 дольше. При этом, если из SSMS сделать вызов так же через 'exec sp_executesql' (это не я, это DataAdapter так работает), то всё ок, тоже быстро отрабатывает. Код client_app_name SSMS .Net Sql Client Data Provider batch_text <sql> - statement - exec sp_executesql n'<sql>' object_name - sp_executesql ---- attach_activity_id.seq 2 1 cpu_time 1 939 000 28 203 000 duration 1 526 567 28 508 694 event_sequence 601 2 538 logical_reads 839 028 2 111 781 physical_reads 0 0 query_hash 0 0 row_count 759 759 writes 1 665 0 Добавлено через 54 секунды P.S.: физически один и тот же сервер, одна и та же база, в обоих случаях подключение к базе из локально запущенного экземпляра приложения. 1

@Andrey-MSK 2866 / 1984 / 369 Регистрация: 14.08.2018 Сообщений: 6,467 Записей в блоге: 4
	19.11.2024, 14:44	4
	А если вот это Сообщение от kotelok batch_text <sql> засунуть в хранимку (`CREATE PROC`) и вызывать её через `SqlCommand()`. По идее сервер должен будет её скомпилировать и сохранить для неё план запроса, и потом всегда использовать его до кардинальных изменений в хранимке... 0

@Andrey-MSK 2866 / 1984 / 369 Регистрация: 14.08.2018 Сообщений: 6,467 Записей в блоге: 4
	19.11.2024, 15:18	6
	Сообщение от kotelok update statistics Полезная штука, особенно когда идёт интенсивное обновление (запись, обновление, удаление) данных в БД. Перестраивает все индексы и после этого запросы начитают работать гораздо быстрее. Для 1С, где-то читал рекомендации, это нужно делать пару раз в месяц... На своей БД делаю это после массового залива спецификаций чертежей 1

@Usaga 12568 / 8742 / 1311 Регистрация: 21.01.2016 Сообщений: 32,782
	19.11.2024, 15:56	7
	Сообщение от kotelok var dt = new DataTable(); adapter.Fill(dt); Зачем? На дворе 2006й год? Используй чистый ADO.NET. И не надо забывать, что выгребание данных из базы и их материализация тоже время и ресурсы занимает. Особенно, когда этих данных дофига. 0

@kotelok 1290 / 869 / 258 Регистрация: 08.08.2014 Сообщений: 2,484
	19.11.2024, 15:59 [ТС]	8
	Сообщение от Usaga Зачем? На дворе 2006й год? Используй чистый ADO.NET. Затем, что это старый сервис, который стабильно работает и на полную переработку которого никто не будет выделять время. Сообщение от Usaga И не надо забывать, что выгребание данных из базы и их материализация тоже время и ресурсы занимает. Особенно, когда этих данных дофига. В данном случае проблема на стороне SQL Server. После обозначенных выше странных процедур, он начал корректный план применять в т.ч. и для запросов из приложения. 0

@Usaga 12568 / 8742 / 1311 Регистрация: 21.01.2016 Сообщений: 32,782
	19.11.2024, 16:07	9
	Сообщение от kotelok В данном случае проблема на стороне SQL Server. После обозначенных выше странных процедур, он начал корректный план применять в т.ч. и для запросов из приложения. Если из приложения вызывается хранимка, то ей можно добавить WITH RECOMPILE. Мы такое в старом сервисе тоже иногда применяли, когда неверный план запроса использовался. 1