Мониторим тяжелые запросы

13.05.19

База данных - HighLoad оптимизация

Мониторинг тяжелых запросов с сохранением результатов для истории.

Выполняя работы по укрупнению наших БД, производим всяческие оптимизации с целью снижения нагрузки на СУБД.

Одним из способов такой оптимизации является поиск тяжелых запросов. Далее определяем, что это за запросы, правим их.

В рамках публикации будет описан мониторинг запросов, создающих наибольшую нагрузку на CPU СУБД. Основой являются материалы ИТС.

На начальном периоде наших работ по оптимизации, пользовались обычной консолью MSSQL: копипастили в нее поисковый запрос, смотрели результаты, делали выводы и что-то дорабатывали. Но уже начали напрягать лишние движения по поиску файла запроса, его запуску и проч. И самое главное, исторической картины мы так и не имели. Т.е., иногда и непонятно, каков же был эффект от доработок.

Поэтому решили возложить всю работу по сбору статистики на сам MSSQL. Теперь он ежечасно запускает хранимую процедуру, которая дописывает данные в специальную таблицу (top_cpu_usage).

 
 Скрипт для таблицы

Поля таблицы совпадают с полями системной view sys.dm_exec_query_stats.

 

Хранимая процедура (sp_store_top_cpu_usage_data) написана по мотивам выше упомянутых материалов ИТС. Ее выполнение немного оптимизировано по сравнению с исходным запросом.

 
 Скрипт для хранимой процедуры

С использование GUI консоли MSSQL создали план обслуживания, ежечасно запускающий ХП.

Вуаля, наши статистики теперь сами собираются и хранятся для истории. Насчет визуализации - пока решаем. Варианты - Grafana, Kibana, MS Power BI.

 

В планах недалекого будущего будет добавление и других таблиц и ХП для сбора данных по другим критериям "тяжести" запросов.

И вот, продолжение статьи.

Вступайте в нашу телеграмм-группу Инфостарт

MSSQL highload

См. также

HighLoad оптимизация Системный администратор 1С:Предприятие 8 1С:Управление производственным предприятием Россия Бесплатно (free)

При внедрении УПП сталкнулся с проблемой медленного (по мнению участников проекта) перепроведения документов. Решил протестировать перепроведение документов за одинаковый промежуток времени на разных связках windows и SQL серверов.

1 стартмани

08.09.2011    14654    pulpik    44    

69

HighLoad оптимизация Системный администратор 1С:Предприятие 8 Россия Бесплатно (free)

Путем проб и ошибок, путем тестирования на 200+ живых пользователей, консультаций с десятками Гуру и поиска по сотням официальных и не очень сайтов был разработан оптимальный вариант настроек MS SQL для круглосуточной работы более, чем 200 пользователей одновременно.

17.02.2010    650393    a-novoselov    255    

860

HighLoad оптимизация Системный администратор Программист Россия Бесплатно (free)

http://gilev.ru/1c/hardware/RAID.html Существуют рекомендации, которых 1С-специалисты не читают, а зря. Вот например эта...

05.12.2008    25231    Gilev.Vyacheslav    38    

54

HighLoad оптимизация Системный администратор Программист 1С:Предприятие 8 Россия Бесплатно (free)

Цель использования: разгрузить процессор, когда два или более пользователей пытаются провести документ. 1С пытается заблокировать таблицы, но делает это без пауз, и загружает процессор на 100%. При этом пользователи практически "встают", и нормальная работа прекращается. Компонента (или патч) позволяет решить эту проблему и нормализовать работу пользователей. Особенно актуально при работе в режиме сервера терминалов.

13.12.2007    67057    7951    romix    82    

223
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. capitan 2570 24.04.19 14:03 Сейчас в теме
Статья открылась с предложения от которого немного повеселело
С использование GUI консоли MSSQL создали план обслуживания, ежечасно запускающий ХП

А так конечно задумка хорошая
Интересно еще как по вашему - какую часть проблем 1С снимает исправление тяжелых запросов, тем более не факт что они неправильные ?
2. ImHunter 344 24.04.19 14:55 Сейчас в теме
(1) Честно, не понял, от чего повеселело)

По поводу "какую часть проблем..." - свежие выводы.
Например, увидели, что большая часть нагрузки приходится за запись (insert) ТЧ определенного вида док-тов. Думаем вот, что нужно поменять архитектуру и отказаться от ТЧ в пользу РС.
Еще увидели, насколько много у нас разыменований определенных справочников. Нашли крупный источник, пофиксили, оценили эффект и решили пока остановиться на этом.
Добавили пару-тройку явно необходимых индексов.
3. capitan 2570 24.04.19 15:43 Сейчас в теме
(2)От великая и могучая русская языка )
4. Aleksey.Bochkov 3711 25.04.19 09:11 Сейчас в теме
Какую версию SQL Server используете?
В 2016 и последующих версиях появился Query Store - по-русски вроде называется Диспетчер Хранилица Запросов.
Собирает самую базовую информацию по запросам, которые потребляют много ресурсов, вместе с их планами и аггрегированной основной статистикой.
Не заменит полноценную систему мониторинга типа RedGate, но зато бесплатно и чрезвычайно удобно.

Тут не нашел публикации, поэтому наверное надо написать простую статью :).
5. ImHunter 344 25.04.19 09:39 Сейчас в теме
(4) Пользуем 2012. Но судя по перечисленному - в служебной вьюхе все это тоже есть. И планы, и аггр статистика.
6. Aleksey.Bochkov 3711 26.04.19 12:30 Сейчас в теме
(5) Добавил описание Query Store здесь - https://infostart.ru/public/1054413/
7. ivanow-sv 14.05.19 12:35 Сейчас в теме
я так понимаю это все только для MS? Postgre в пролете?
8. ImHunter 344 14.05.19 12:50 Сейчас в теме
(7) Для PG вроде есть свои источники подобных статистик. Сходу нашел что-то про pg_stat_activity. Ну понятно, что один в один не применить.
Для отправки сообщения требуется регистрация/авторизация