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

 

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

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

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