Нюансы 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.

Запись опубликована в рубрике VMware, vSphere с метками . Добавьте в закладки постоянную ссылку.

5 комментариев: Нюансы CPU Ready

  1. pkruchok говорит:

    >>>>То есть, ваши гигагерцы, указанные в vClient, становятся нечестными.<<<<>>>В ESXTOP этот параметр так и отображается, в vClient он меряется в миллисекундах и вам необходимо провести несложные вычисления.<<<<<
    В клиенте этот параметр виден и в %, если смотреть в "overview" режиме (на кажый vCPU и суммарно на всю виртуалку).

  2. pkruchok говорит:

    >>>>То есть, ваши гигагерцы, указанные в vClient, становятся нечестными.

    У меня на хостах с включенным HT, доступные гигагерцы считаются только исходя из реальных физических ядер. Так что все честно 🙂

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

    В клиенте этот параметр виден и в %, если смотреть в «overview» режиме (на кажый vCPU и суммарно на всю виртуалку).

  3. Андрей Вахитов говорит:

    Блин 🙂
    Действительно, это так.

  4. Алексей Катков говорит:

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

    У меня есть два сервака (терминалы Windows 2003 с 1с 7.7 и 8.2). У них если Ready становится больше чем 1-2% на процессор начинаются неприятности в виде обрывов (в основном с автоматическим переподключением) сессий клиентов (с MS SQL связь стабильная). Остальные (терминалы Windows 2003 с MS Office и прочим) «кушают» (правда притормаживая) и положенные 10% на vCPU без вопросов. Нстройки сети везде одинаковые.

    НТ у меня существенно улушает дела (на 12 ядер с НТ до 40 ВМ, некоторые до 50 vCPU). 25% дополнительных ВМ получил (процессор больше чем на 78% занят не бывает) с сохранение приемлемого Ready

  5. Андрей Вахитов говорит:

    Добрый день, Алексей. Я склонен метаться между значениями 5% и 10%.
    А проблема точно в CPU Ready с вашими терминалами?
    То есть, с резервированием ресурсов все работает как часы. Снимаете резервирование процессора — в часы пик начинают происходить разрывы?

    Вообще говоря, странное поведение. А сервер SQL находится на этом же сервере или другом?

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

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