MS SQL Server, проблема с нехваткой ресурсов CPU и способ ее решения

 

MS SQL server monitoring

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

Система работала вполне успешно длительное время, после чего начали проявляться проблемы. Сборщики данных по отдельным серверам в отдельные моменты данные НЕ собирали. По внутренним счетчикам перегрузки MS SQL Server не наблюдалось. Запросы были оптимизированы, это для меня профильный вопрос 🙂 Не помогло 🙁

При этом на сервере появлялась странная диспропорция между CXPACKET ms (распараллеливание, очень грубо –  нагрузка CPU на сложных запросах) и SOS_SCHEDULER_YIELD ms (отказ процесса от выполнения, первое свидетельство недостатка ресурсов CPU). Почему-то образовалось bottleneck без объективных на то предпосылок. Сервер вроде нормальный, 8-ядерный Intel® Xeon® E5

Искал долго, причина оказалась проста и даже очевидна. Часть данных собиралась отдельными запросами, запросами небольшими. Для этого запускался job с конструкцией вроде

 

EXEC master..xp_cmdshell '***'

 

Для улучшения производительности скрипты выполнялись параллельно конструкцией вроде
start /min /LOW "***" call ***.bat **** **** | EXIT

 

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *