11.4.7. Счетчики для анализа загрузки процессора

Анализ загрузки процессоров средствами Системного монитора, % загруженности процессора (% Processor Time), Длина очереди процессора (Processor Queue Length), % работы в привилегированном режиме (% Privileged Time), % времени прерываний (% Interrupt Time), распараллеливание запросов, context switching, cost threshold for parallelism, флаг трассировки 8687

Главный счетчик для анализа загрузки процессора — % загруженности процессора (% Processor Time) для объекта Процессор (Processor). Значение этого счетчика не должно превышать 80% в течение длительного промежутка времени. Если оно стабильно больше, то это значит, что процессорная подсистема работает с перегрузкой и является узким местом сервера. Пора обновлять процессор, или снимать с сервера часть нагрузки, или переходить на многопроцессорную систему, или задуматься о применении 64-разрядной платформы. Отметим только один важный момент: высокое значение счетчика загрузки процессора может возникнуть из-за дефицита оперативной памяти или перегрузки дисковой подсистемы. Поэтому вполне может получиться так, что добавление оперативной памяти или замена RAID-массива на более быстрый одновременно решит проблему с процессором.

Если вы производите мониторинг производительности мультипроцессорной системы, то для оценки загрузки всех процессоров можно использовать экземпляр _Total того же объекта Процессор. В предыдущих версиях операционной системы для этой цели был предназначен счетчик % общее время загруженности процессоров для объекта Система (System), но в Windows Server 2003 его уже нет.

Есть еще несколько счетчиков, относящихся к работе процессора, которые нужно принимать во внимание:

q      Длина очереди процессора (Processor Queue Length) для объекта Система. Этот счетчик показывает, сколько запросов стоит в очереди на обработку центральным процессором. Значение этого счетчика не должно в течение продолжительного времени превышать количество процессоров в системе, умноженное на 2 (например, если на сервере 4 процессора, то это значение не должно быть больше 8);

q      % загруженности процессора (% Processor Time), но уже для другого объекта — Процесс (Process), и конкретно для экземпляра объекта sqlservr с нужным номером. Этот счетчик показывает, сколько времени затрачивается процессором на обслуживание запросов SQL Server. Этот показатель рекомендуется сравнивать с аналогичным показателем для других процессов. Может выясниться, что ваш сервер тратит свои силы на что-то еще;

q      % работы в привилегированном режиме (% Privileged Time) для объекта Процессор. Этот параметр показывает, сколько времени тратится на обслуживание запросов ядра. Это время должно быть как можно меньше: на загруженном сервере все ресурсы должны отдаваться серверным приложениям (т. е. SQL Server). Если значение счетчика большое (составляет десятки процентов), то нужно проверить, нет и у вас проблем с системой. Например, сильно загрузить процессор может неправильно сконфигурированное оборудование. Проверить это можно при помощи следующего счетчика;

q      % времени прерываний (% Interrupt Time) для объекта Процессор. Этот параметр показывает, сколько времени процессор тратит на обработку прерываний от оборудования. Если при установке какого-либо оборудования значение этого счетчика сильно возрастает, с этим оборудованием наверняка какие-то проблемы.

При работе на многопроцессорных системах иногда возникает еще одна проблема. Она заключается в том, что SQL Server не всегда корректно производит распараллеливание при выполнении запросов. За счет избыточного числа переключений между процессорами (context switching) скорость выполнения запроса на многопроцессорной системе может оказаться заметно ниже, чем на однопроцессорной. В этой ситуации в вашем распоряжении есть два решения:

q      использовать параметр настройки сервера cost threshold for parallelism (его можно настроить при помощи хранимой процедуры sp_configure). Он определяет стоимость запроса, начиная с которой выполнения этого запроса будет распараллеливаться. По умолчанию в SQL Server 2000 и SQL Server 2005 для этого значение установлено значение 5. Это значит, что будут распараллеливаться запросы, ожидаемое время выполнения которых больше 5 секунд (на самом деле такой порог будет заметно меньше 5 секунд, поскольку "калибровка" единиц стоимости производилась в середине 90-х годов при разработке SQL Server 7.0). Увеличение значения этого параметра приведет к тому, что будет распараллеливаться меньшее количество запросов. Однако проблема распараллеливания больших запросов все равно останется;

q      использовать флаг трассировки 8687. Он просто запрещает распараллеливание запросов. Кроме решения проблем с некорректным распараллеливанием, его применение дает дополнительные важные преимущества: особо "тяжелый" запрос не сможет захватить все ресурсы всех процессоров, и он повлияет на работу других пользователей в меньшей степени.

По опыту проведения автором курсов по SQL Server, отмечено, что этот флаг используется специалистами на очень многих предприятиях, поскольку без него работать бывает достаточно сложно. Включить флаг трассировки можно так:

-- Вначале определяем, что флаг будет распространен на все подключения

DBCC TRACEON(-1);

-- Затем включаем сам флаг трассировки

DBCC TRACEON(8687);

Можно настроить автоматическое включение этого флага трассировки при запуске сервера. Для этого при запуске службы SQL Server используется параметр командной строки -T с номером флага трассировки. В этом случае флаг будет автоматически применяться ко всем клиентским подключениям.

Для просмотра информации о всех установленных флагах трассировки можно использовать команду:

DBCC TRACESTATUS(-1)

Получить учебные материалы по этому курсу