Повышенная нагрузка на процессор сервера баз данных – часто встречающаяся проблема в работе ИС. Однако, не всегда она интерпретируется правильно и, соответственно, не всегда правильно определяются способы её устранения. Сама по себе повышенная (близкая к 90-100%) нагрузка на процессор негативно влияет на общую производительность сервера баз данных, так как в процессе работы и служба и программа нуждаются в ресурсах процессора.

Если свободного ресурса процессора нет, то программы «встают» в очередь на его получение. Отсюда первая рекомендация: обращать внимание не только на % загрузки процессора (например, через диспетчера задач или стандартные счетчики Windows), но и на такой показатель, как «Длина очереди процессора» (Processor Queue Length). Зачастую именно этот показатель нагляднее демонстрирует недостаточность ресурсов процессора и проблемы с этим связанные.

Приведу наглядный пример: если у некоторого ПО есть ограничение на количество ядер процессора, согласно лицензионному соглашению, то анализируя нагрузку по процессору только по «% загрузки», вы будете заложниками неправильной интерпретации и только оценка длины очереди процессора может дать окончательное подтверждение или опровержение выводов. Если длина очереди процессора не уменьшается ниже 1-2 в течение длительного времени – это признак того, что процессор не справляется с задачами. Скачки 5-10 – первые симптомы недостаточности ресурсов процессора.

Слева показаны три графика: Нагрузка на процессор %, длина очереди процессора, время отклика MS SQL (это синтетический счетчик показывающий время выполнения простого запроса на MS SQL).

Рисунок 1. PERFEXPERT. Окно консоли управления. Нагрузка процессора.

С помощью линейки мы зафиксировали абсолютные значения этих счетчиков: 65% процессор, 26 – длина очереди, 171 мс время отклика (при нормальном — 30мс). Если бы мы не учитывали второй график, то падение отклика сервера баз данных в 5-6 раз мы бы не связали с нагрузкой на процессор, так как она была 65%. Но очередь к процессору четко нам доказывает эту связь. Обратите внимание, как только очередь к процессору уменьшилась до 0, то отклик MS SQL восстановил свое нормальное значение. Стоит упомянуть, что в случае 95-100% загрузки процессора смотреть на длину очередь к процессору нет необходимости.

После того, как мы разобрались с правильной интерпретацией проблем с процессорным ресурсом, разберемся с основными причинами:

1. Неравномерное распределение нагрузки между сессиями MS SQL Server, в основном за счет параллелизма.
Это наиболее часто встречающаяся ситуация, при которой одна или несколько сессий может «захватить» все ресурсы процессора.

Рисунок 2. PERFEXPERT. Окно консоли управления. Неравномерное распределение нагрузки на процессор.

Как видно из рисунка, в определенные моменты времени нагрузка на процессор была 100%. При этом отклик MS SQL ухудшился более 10 раз. Следовательно, в период такой нагрузки все операции ухудшатся и будет общая деградация производительности. На рисунке 2 выделен сеанс, который привел к этой ситуации (68 spid). Скорее всего, данный сеанс выполнял запрос и сервер баз данных его распараллелил. Таким образом, сеанс потребил более 22 ядер процессора из общего количества 24. Такие ситуации необходимо правильно интерпретировать при работе ИС и администраторам в будущем необходимо ограничивать ресурсы процессора для каждой сессии.

2. Сторонние процессы Windows

Часто сервер баз данных выполняет не одну, а несколько ролей. Например, сервер баз данных и сервер терминалов или сервер баз данных и сервер приложения. Это приводит к ситуациям, когда появляется конкуренция за ресурсы между ними (за оперативную память, за дисковые хранилища, за ресурсы процессора).

Рисунок 3. PERFEXPERT. Окно консоли управления. Нагрузка процессора, обусловленная внешними процессами.

На рисунке 3 кроме трёх графиков мы добавили еще один: нагрузка процессора, обусловленная MS SQL (второй график). Как видно из рисунка, только 32% ресурсов процессора используется службой MS SQL, остальные сторонними приложениями (в нашем случае 1cv7). При этом ухудшается отклик MS SQL. Во многом этой ситуацией и объясняется рекомендация разнесения ролей на различные аппаратные ресурсы.

3. Устаревание кеша процедур MS SQL Server, отсутствие обслуживания БД (обновление статистики, переиндексация)
Как правило, нагрузка процессора в ситуациях неправильного обслуживания БД возникает неожиданно, например, все работало без проблем и, вдруг, с утра нагрузка на процессор увеличилась в 3 раза. При этом накануне не было мероприятий по обновлению ПО и подобные. Имеет смысл в подобных ситуациях проверить качество выполняемых задач по обслуживанию, проанализировать «тяжелые» запросы SQL (потребляющие значительные ресурсы процессора) и после анализа определить таблицы и индексы, которые следует обновить в первую очередь. Не лишним будет обнуление кеша процедур, хотя во многих ситуациях в высоконагруженных системах это надо делать очень осторожно. Для данных мероприятий рекомендуем привлечение компетентных администраторов баз данных и специалистов по производительности.

Наиболее удобным инструментом для анализа и сбора данных по работе ИС: например, нагрузка на процессор %, длина очереди процессора, время отклика MS SQL, нагрузка процессора, обусловленная MS SQL и много другого; является решение PERFEXPERT. С не имеющем аналогов продуктом можно ознакомиться на официальном вебсайте SOFTPOINT.