У специалиста с небольшим опытом анализ счетчиков производительности CPU, как собственно и любых других, часто вызывает достаточно много сложностей и это неудивительно, учитывая многообразие счетчиков. В этой статье я постараюсь рассмотреть основные случаи, которые могут встретиться среднестатистическому админу, а также расскажу алгориты принятия решений
Если вам интересны счетчики производительности Windows, рекомендую обратиться к основной статье тематики – Счетчики производительности.
Анализ счетчиков производительности CPU
Для начала хочу уточнить один момент – существует две группы счетчиков производительности процессора, это группы Процессор (Processor) и Сведения о процессоре (Processor Information). Обе они имеют разный набор счетчиков (подробнее читайте в статье Счетчики производительности процессора), но я буду рассматривать только те из них, которые присутствуют в обоих группах. То есть вы можете использовать любую группу на ваш выбор.
В первом случае полное название счетчика (на примере % Processor Time) будет иметь вид:
\Processor Information(_Total)\% Processor Time (русскоязычная версия – \Сведения о процессоре(_Total)\% загруженности процессора)
, во втором случае:
\Processor(_Total)\% Processor Time (русскоязычная версия – \Процессор(_Total)\% загруженности процессора)
Итак, начнем.
Первым делом нужно для себя определить на какие именно счетчики обращать внимание в первую очередь. В случае с основными показателями производительности CPU главным счетчиком является % Processor Time. Именно с его показаний и нужно искать проблему. При этом, по моим наблюдениям, нормальной считается средняя нагрузка до 60%, нагрузка 85% и выше уже представляет из себя большую проблему. Учитывая тот факт, что даже на стресс-тестах загрузка ЦП находится в районе 95%, то для серверов в продакшене 85% – это критическая загруженность.
Норма % Processor Time – до 60%, критическая – 85% и выше
1. Смотрим показания % Processor Time и, допустим, в вашем случае нагрузка ЦП действительно близка к критической и нужно что-то делать. Увеличивать процессорную мощность спешить не нужно, для начала посмотрите другие счетчики и уже после этого делайте выводы.
2. Чтобы на всякий случай убедиться в корректности показаний % Processor Time, открываем счетчик % Idle Time и смотрим какие средние значения он имеет. Этот счетчик показывает % простоя ЦП, то есть % времени, в которое ваш процессор не выполнял никаких задач. Следуя логике, показания этого счетчика должны быть = 100 – % Processor Time.
Норма % Idle Time обратно пропорциональна % Processor Time и составляет не ниже 40%, критическое значение – ниже 15%
С % Idle Time все в порядке, но легче нам не стало, идем дальше.
Пришло время посмотреть что нам покажут счетчики % Privileged Time и % User Time.
3. Смотрим счетчик % Privileged Time – время работы в привилегированном режиме – и если он в среднем держится выше 10%, это повод задуматься.
Норма % Privileged Time составляет <10%, о проблемах говорят значения >20%
Стоит отметить, что норму для % User Time определить достаточно трудно, ведь этот счетчик говорит о полезной нагрузке, которую выполняет ваш сервер. Грубо говоря, счетчик отображает % времени ЦП, которое тратится на обработку данных приложений, которые вы и запустили. Учитывая тот факт, что % Processor Time = % User Time + % Privileged Time, то в идеале значения % User Time должны стремиться к % Processor Time, а доля % Privileged Time стремиться к 0. Но это в идеале, в реальности же никак не убрать ту нагрузку, которую генерирует ядро ОС (она как раз и составляет % времени работы в привилегированном режиме).
Предположим % Privileged Time действительно показывает неприличные значения и нам надо что-то с этим делать.
4. Самое время обратиться к счетчику % Interrupt Time. Он отображает % времени, которое ЦП тратит на обработку прерываний. В идеале значение должно стремиться к 0, но на практике это бывает редко. Чаще всего нормальные значения составляют меньше 1%.
Норма % Interrupt Time – <1%, критические значения – >5%
Если вы заметили ненормальные показания счетчика % Interrupt Time, это может говорить о проблемах с оборудованием, которое является причиной генерирования большого количества прерываний. Вообще отслеживать значения счетчика рекомендуется сразу после изменения аппаратной конфигурации и в случае аномального увеличения количества прерываний, принимать какие-то меры (например подобрать драйверы, с которыми устройство ведет себя лучше всего). Чтобы подкрепить свои наблюдения, можно обратить внимание на счетчик Interrupts/sec. Он показывает абсолютные значения прерываний в секунду.
Норма Interrupts/sec на каждом процессоре своя, оптимальные значения нужно определять эмпирическим путем совместно с данными % Interrupt Time
Допустим проблема была в недавно установленной сетевой карте. Вы поставили драйверы и проблема ушла сама собой и значения % Processor Time вернулись в нормальный диапазон. А что, если у вас изначально была другая ситуация? Про исключения из озвученного выше сценария я расскажу ниже.
Исключения из правил
1.а Что делать, если показания счетчика % Processor Time идеальны (стабильно <60%), но пользователи все равно жалуются на медленную обработку данных. Первой и самой очевидной проблемой может быть узкое место другого компонента сервера:
- нехватка оперативной памяти;
- недостаточная производительность дисковой подсистемы;
- маленькая пропускная способность сетевой карты.
В этих случаях нужно обратиться к счетчикам производительности других групп и в рамках этой статьи я не буду рассматривать эти сценарии (мы ведь тут говорим о процессоре, а не о дисках или оперативке). Тем не менее, даже если проблем с RAM, HDD, сетью нет, узким местом все равно может быть процессор! Но в какую сторону копать? Для начала посмотрите показания счетчика % C3 Time. Он говорит о % времени, которое ЦП провел в одном из состояний пониженного энергопотребления, а именно в состоянии C3 (реально их значительно больше 1).
В норме ЦП не должен переходить в состояние C3, то есть показания % C3 Time должны быть = 0
Подкрепить ваши наблюдения поможет счетчик C3 Transitions/sec, показывающий абсолютные значения переходов в состояние C3 в секунду. Почему именно C3? Дело в том, что начиная с C3, выход из состояний занимает значительное время и ЦП может попросту заниматься не тем, чем должен. Тем не менее, бывают проблемы и с C1, C2. Есть мнение 2, что работе всем известного сервера 1С Предприятие может очень сильно мешать переход в состояния пониженного энергопотребления и рекомендуют вообще отключать такую возможность на уровне BIOS вашего сервера (правда рекомендация касается C1E).
Постоянный мониторинг счетчиков % C1 Time, % C2 Time, C1 Transitions/sec, C2 Transitions/sec, C3 Transitions/sec на мой взгляд излишен, но периодически стоит обращать на них внимание.
1.б Ситуация аналогичная – показания счетчика % Processor Time идеальны (стабильно <60%), но пользователи все равно жалуются на медленную работу серверного приложения. Проблемой также может быть недостаточная мощность процессора для обработки пиковых значений. 95% времени ваш ЦП может быть загружен на какие-то жалкие 10-15%, но в оставшиеся 5% времени идут требовательные к процессорной мощности запросы и ЦП обрабатывает их недостаточно быстро.
Причиной может быть морально устаревшее оборудование (медленная шина данных, небольшой процессорный кэш и т.п.). В некоторых компаниях серверы могут работать десятилетиями, но придет все же тот час, когда сервер устанет и апгрейдить его возможности не будет не потому что денег нет, а потому что запчасти к нему уже давно не выпускаются. Проводите плановую замену своих “вёдер”, товарищи.
3.а Имеем норму % Privileged Time, но стабильно высокие значения % Processor Time. Это классический случай нехватки процессорной мощности для нормального выполнения возложенных на сервер задач. Единственная рекомендация – увеличьте количество vCPU (в случае с виртуальными машинами) или перенесите роли сервера на другое оборудование/произведите апгрейд имеющегося.
Пожалуй, выше были рассмотрены самые часто встречающиеся сценарии и на этом статью можно завершить. Делитесь своим опытом в комментариях.
Notes:
