Нюансы CPU Ready

Товарищи из VMkernel написали еще один интересный документ, посвященный метрике CPU Ready. С ней не все однозначно, поэтому я с интересом взялся за перевод.

CPU Ready – это метрика, показывающая сколько времени процесс стоял в ожидании процессорного времени.

Имеются следующие предпосылки к высокому CPU Ready:

1) Переиспользование (Oversubscription) процессора. То есть соотношение количества физических процессоров (PCPU или “ядер”) к количеству виртуальных процессоров (VCPU – процессоров виртуальных машин). Согласно vSphere 5 Configuration Maximums на одно ядро можно впихнуть до 25 виртуальных процессоров. Чудес не бывает – эти процессоры должны быть должным образом ненагружены, чтобы такой фокус удался. VMKernel предлагает следующие варианты:

– от 1:1 до 1:3 – все ок;

– от 1:3 до 1:5 – могут быть проблемы из-за конкуренции за ресурсы;

– от 1:5 – скорее всего будут проблемы.

Тут же стоит помнить о Hyper-Threading: эта технология удваивает количество PCPU, но полноценно выполняться код может только на одном из пары.

Ситуацию с задержкой из-за HT можно увидеть в ESXTOP/RESXTOP. После запуска нажимаете “F” и добавляете поля “I:  SUMMARY STATS = CPU Summary Stats”. Параметр “%LAT_C” как раз и отвечает за задержки по вине процессора. Обратите внимание еще и на параметр “%LAT_M” – он отвечает за задержки по вине оперативной памяти (например, свопа).

2) Использование лимита процессорного ресурса

Хотя это не рекомендуется, вы можете задать ограничение на количество используемых ресурсов (процессора или памяти) для ВМ или пула ресурсов. В этом случае метрика %RDY будет ненулевой. Данную ситуацию легко можно увидеть, так как в этом случае также ненулевой будет метрика %MLMTD (также включенная в %RDY). То есть для понимания “чистого” CPU Ready вам необходимо из %RDY вычесть %MLMTD.

3) Привязка vCPU к PCPU.

Для определенной виртуальной машины вы можете задать CPU Affinity – список физических процессоров, на которых виртуальная машина может выполняться. В этом случае scheduler не сможет раскидать нагрузку по разным процессорам, и ВМ могут недополучать процессорное время, хотя есть свободные процессоры. Практический смысл тут один – если вы не хотите лицензировать N процессоров физического сервера (например для SQL), задаете подобное соответствие. Вроде бы в этом случае можно купить столько лицензий, на скольки процессорах может работать ВМ.

Ну и подводный камень – vMotion то ли не работает, то ли сбрасывает эту настройку.

4) Использование Fault Tolerance

Если при использовании FT ресурсов хостов не хватает для обеспечения реплики, то машина источник начинает притормаживать. При этом также будет увеличен счетчик %MLMTD.

Основные заблуждения относительно производительности CPU

1) Дополнительный PCPU, получающийся засчет HyperThreading, не дает такой же производительности, как дополнительное ядро. То есть, ваши гигагерцы, указанные в vClient, становятся нечестными. В документе приводится цифра в 75%, на мой взгляд она достаточно оптимистичная. При проектировании это надо учитывать.

2) Большое количество гигагерц, доступных на ваших хостах, вовсе не означает, что вы можете их без проблем “снять”.

3) Прямой зависимости между vCPU Usage и CPU Ready нет. Правильнее сказать – оно зависит от… 🙂

4) DRS не помогает решать вопросы с CPU Ready. Он всего лишь оценивает загрузку ЦПУ хоста для принятия решения о миграции.

Сколько CPU Ready считать нормальным?

Авторы статьи считают 5% на один vCPU. Duncan Epping считает – 10%.

В ESXTOP этот параметр так и отображается, в vClient он меряется в миллисекундах и вам необходимо провести несложные вычисления.

Например, у вас есть двухпроцессорная машина, CPU Ready которой составляет 5000ms. Так как период сбора статистики составляет 20 секунд, нам необходимо разделить измеренное значение на 20000. И для подсчета “CPU Ready per processor” поделить также на количество процессоров.

%RDY=5000/20000/2 = 12.5%

Также можно почитать VMGU.RU, Yellow Bricks и VMware Community.