<< Click to Display Table of Contents >> Администрирование (Windows) > Сопровождение работы системы > Анализ быстродействия СУБД Microsoft SQL Server Рекомендации по анализу ситуаций |
![]() ![]() |
В зависимости от сложности ситуации рекомендации по анализу могут отличаться:
•замыкание коллекции с сущностями
•в статистике запрос отображается длительным
Замыкание коллекции с сущностями
При замыкании большого количества данных (десятки или сотни тысяч сущностей) может перезапуститься сервис. Это происходит из-за нехватки оперативной памяти на сервере.
В таком случае проанализируйте лог-файлы системы и найдите запросы к веб-серверу, которые возвращают большое количество записей. Чтобы отслеживать такие запросы, используйте в конфигураторе Directum Launcher параметр FETCHED_RECORD_COUNT_WITHOUT_WARNING. Также можно проанализировать данные в решении «Мониторинг системы Directum RX» с помощью дашборда Large Fetches.
Рекомендуется избавиться от замыкания. Если без него обойтись нельзя, то вместо получения сущности целиком реализуйте получение только одного свойства этой сущности. Иначе разбейте выгрузку на несколько частей и обрабатывайте каждую сущность отдельно.
В статистике запрос отображается длительным
При сборе статистики с фильтром по длительности запрос может отобразиться как длительный, а при проверке на СУБД выполниться быстро.
Такая ситуация возможна, если:
•запрос ожидает освобождения блокировки ресурсов. В этом случае в профилировщике фиксируются большие значения общего времени выполнения (Duration) и низкие затраты процессорного времени (CPU).
Рекомендуется проанализировать причину блокировки ресурсов.
•запрос выполняется в транзакции, например нумерация документа при его сохранении. Так как вносятся изменения в таблицу с нумерацией документов, устанавливается блокировка на страницу данных. Из-за этого другие запросы по нумерации ждут, пока страница разблокируется.
Рекомендуется создать новое соединение к базе данных и нумеровать документ в отдельной транзакции. Например, если транзакция отменяется, но запись номера в базе данных уже занята, могут возникнуть ошибки.
Также проанализируйте причины такой проблемы: какое действие в транзакции выполняется долго, и по возможности перепишите код для ускорения выполнения транзакции.
•для запроса строятся разные планы выполнения.
Рекомендуется собрать планы выполнения профилировщиком и сравнить их с фактическим из SSMS. Если они отличаются, то обновите статистику.
Иногда запрос выполняется медленно из-за неверной статистики. Например, пересчет папок потока занимает много времени. При неактуальной статистике анализ запросов выполнять бесполезно.
Рекомендуется при анализе плана запроса обращать внимание на показатели Actual Number of Rows и Estimated Number of Rows. Если они сильно отличаются, значит статистика некорректная и ее нужно обновить. После обновления план запроса может сильно поменяться и стать более подходящим.
В данном случае может помочь применение системной процедуры sp_updatestats и настройка или корректировка регулярной актуализации статистик, чтобы избежать таких ситуаций в будущем.
© Компания Directum, 2024 |