Сколько конфликтов слишком много в VMware?

Некоторое время я пытался выяснить, почему довольно многие из наших критически важных для бизнеса систем получают сообщения о «медлительности», варьирующейся от умеренной до экстремальной. Недавно я обратил свой взор на среду VMware, где размещены все рассматриваемые серверы.

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

Я посмотрел на эту статью VMware KB ; специально для определения Co-Stop, которое определяется как:

Количество времени, в течение которого виртуальная машина MP была готова к запуску, но возникла задержка из-за конфликта планирования со-vCPU

Который я перевожу на

Гостевой ОС требуется время от хоста, но он должен ждать, пока ресурсы станут доступными, и, следовательно, может рассматриваться как "не отвечающий"

Этот перевод кажется правильным?

Если это так, то здесь мне трудно поверить в то, что я вижу: хост, который содержит большинство «медленных» виртуальных машин, в настоящее время показывает среднее значение Co-stop ЦП 127 835,94 миллисекунды!

Означает ли это, что в среднем виртуальные машины на этом хосте должны ждать 2+ минуты для процессорного времени ???

Этот хост имеет два 4-х ядерных процессора и имеет гостевой процессор 1x8 и гостевой процессор 14x4.

Я могу описать некоторые из опытов, которые я имел в этой области ...

Я не верю, что VMware делает адекватную работу по информированию клиентов ( или администраторов ) о передовых практиках, а также не обновляет прежние передовые практики по мере развития их продуктов. Этот вопрос является примером того, как основная концепция, такая как распределение vCPU, не полностью понята. Наилучший подход - начинать с малого, с одного vCPU, пока вы не определите, что виртуальной машине требуется больше.

Для OP хост-сервер ESXi имеет два четырехъядерных процессора, что дает 8 физических ядер.

Описанная схема виртуальной машины - всего 15 гостей; Системы 1 х 8 и 14 х 4. Это слишком перегружено, особенно с наличием одного гостя с 8 виртуальными ЦП . Это не имеет никакого смысла. Если вам нужна такая большая виртуальная машина, вам, скорее всего, нужен больший сервер.

Пожалуйста, попробуйте изменить размер ваших виртуальных машин. Я почти уверен, что большинство из них могут жить с 2 vCPU. Добавление виртуальных процессоров не ускоряет работу, поэтому, если это исправит проблему с производительностью, это неправильный подход.

В большинстве сред оперативная память является наиболее ограниченным ресурсом. Но процессор может быть проблемой, если есть слишком много конфликтов. У вас есть доказательства этого. ОЗУ также может быть проблемой, если слишком много выделено отдельным виртуальным машинам .

Это возможно контролировать. Метрика, которую вы ищете - «CPU Ready%». Вы можете получить доступ к этому от клиента Vsphere, выбрав VM и собирается Performance> Overview> График CPU.

• Под 5% CPU Ready - все хорошо.
• 5-10% CPU Ready - внимательно следите за активностью.
• Более 10% CPU Ready - не хорошо.

Обратите внимание на желтую линию на графике ниже.

Не могли бы вы проверить это на проблемных виртуальных машинах и отчитаться?

В комментариях вы указали, что у вас есть двухъядерный хост ESXi, и вы используете одну виртуальную машину 8vCPU и четырнадцать виртуальных машин 4vCPU.

Если бы это была моя среда, я бы считал , что быть грубо чрезмерно предусмотренном. Я бы выбрал от четырех до шести гостей 4vCPU на этом оборудовании. (Это предполагает, что у рассматриваемых виртуальных машин есть нагрузка, которая требует, чтобы у них был такой высокий показатель vCPU.)

Я предполагаю, что вы не знаете золотого правила ... с VMware вы никогда не должны назначать ВМ больше ядер, чем нужно. Причина? VMware использует довольно строгое совместное планирование, из-за которого виртуальным машинам сложно получать процессорное время, если не доступно столько ядер, сколько назначено виртуальной машине. Это означает, что виртуальная машина 4vCPU не может выполнить 1 единицу работы, если в одно и то же время не открыто 4 физических ядра. Другими словами, архитектурно лучше иметь виртуальную машину 1vCPU с нагрузкой на процессор 90%, чем виртуальную машину 2vCPU с нагрузкой 45% на ядро.

Итак ... ВСЕГДА создавайте виртуальные машины с минимумом виртуальных ЦП и добавляйте их только тогда, когда это будет необходимо.

В вашей ситуации используйте Veeam для мониторинга использования процессора вашими гостями. Уменьшите количество vCPU как можно больше. Я был бы готов поспорить, что вы можете перейти на 2vCPU практически на всех ваших гостях 4vCPU.

Конечно, если все эти виртуальные машины имеют нагрузку на процессор и требуют подсчета количества виртуальных ЦП, то вам просто нужно купить дополнительное оборудование.

127 835,94 миллисекунды являются суммой, и вам нужно разделить на время выборки, чтобы получить правильные значения% RDY. Похоже, вы уже получаете правильные показания% RDY сейчас. Вы можете довольно сильно увеличить соотношение виртуальных процессоров и физических процессоров, но не так, как вы это делаете.

У вас слишком много четырех виртуальных машин vCPU и даже 8 виртуальных машин vCPU. Уже есть некоторые качественные ответы, в которых обсуждается правильное определение размеров и некоторые последствия не консолидации циклов с меньшим количеством виртуальных ЦП. Единственное, что я хотел уточнить, это то, что хотя виртуальная машина больше не должна ждать, пока количество физических процессоров, равное количеству виртуальных ЦП, не станет доступным, прежде чем любая инструкция может быть обработана, это очень вредно. иметь избыточное обеспечение этой величины отношением виртуальных машин с несколькими виртуальными ЦП к физическим ядрам. 64 виртуальных ЦП на 8 ядрах значительно превышают максимальное соотношение 4 к 1. Я предполагаю, что у вас есть HT на этих процессорах, поэтому у вас есть 16 логических ядер? Это может быть нормально с 1 и 2 виртуальными машинами vCPU, которые имеют небольшую нагрузку, но если у вас большая нагрузка на виртуальные машины, это будет трудно выполнить.

К сведению: Процессоры HT не используются в вычислениях% используемого ЦП. Это означает, что если у вас 32 логических ядра, работающих на сервере с частотой 2,4 ГГц, то вы используете 100% при достижении 38,4 ГГц. Поэтому, когда вы видите средние значения загрузки, показывающие более 1,0, вот почему.

Вот хост ESXi с соотношением виртуальных ЦП 3,5 к 1 к физическому ЦП (включая ядра HT) со средним% RDY 3%.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

С тех пор мы установили Veeam ONE, который пролил немного света на проблемы с производительностью. Посмотрев на экран «Узкие места ЦП» в Veeam ONE, затем воспользовавшись поиском и устранением неисправностей виртуальной машины, которая перестала отвечать: сравнение использования VMM и гостевого ЦП в качестве справки, мы выяснили, где находится наш «недопустимый» конфликт.

Один небольшой совет, которым я хотел поделиться, заключается в том, что в одном случае я не мог устранить конфликт ЦП, пока не удалил снимок, который был на ВМ. Надеюсь, это кому-нибудь поможет.