Я уже некоторое время пытаюсь понять, почему многие из наших критически важных для бизнеса систем получают отчеты о «медленности» от умеренной до экстремальной. Недавно я обратил внимание на среду VMware, где размещены все эти серверы.
Недавно я загрузил и установил пробную версию Veeam VMware management pack для SCOM 2012, но мне (и моему боссу) трудно поверить в цифры, которые он мне сообщает. Чтобы убедить босса в том, что цифры, которые он мне сообщает, верны, я начал изучать сам клиент VMware, чтобы проверить результаты.
Я посмотрел наэта статья базы знаний VMware; в частности, для определения Co-Stop, которое определяется как:
Время, в течение которого виртуальная машина MP была готова к запуску, но возникала задержка из-за конфликта планирования co-vCPU
Который я перевожу на
Гостевая ОС требует времени от хоста, но должна ждать, пока ресурсы станут доступны, и поэтому ее можно считать «неотзывчивой».
Кажется ли вам этот перевод правильным?
Если так, то вот тут мне трудно поверить в то, что я вижу: хост, содержащий большинство «медленных» виртуальных машин, в настоящее время показывает среднее значение совместной остановки ЦП127,835.94миллисекунды!
Означает ли это, что в среднем виртуальным машинам на этом хосте приходится ждать процессорного времени более 2 минут???
На этом хосте установлено два 4-ядерных ЦП, а также 1 гостевой ЦП на 8 ядер и 14 гостевых ЦП на 4 ядра.
решение1
Я могу описать некоторые моменты из своего опыта в этой области...
Я не верю, что VMware проводит адекватную работу по обучению клиентов (или администраторы) о лучших практиках, и они не обновляют предыдущие лучшие практики по мере развития своих продуктов. Этот вопрос является примером того, как основная концепция, такая как распределение vCPU, не полностью понята. Лучший подход — начать с малого, с одного vCPU, пока вы не определите, что виртуальной машине требуется больше.
Для OP хост-сервер ESXi имеет два четырехъядерных процессора, что дает 8 физических ядер.
Описываемая схема виртуальной машины — это 15 гостей; 1 x 8 vCPU и 14 x 4 vCPU систем. Это слишком перегружено, особенно с учетом наличияодин гостевой с 8 vCPU. Это бессмысленно. Если вам нужна такая большая виртуальная машина, вам, вероятно, понадобится сервер побольше.
Пожалуйста, попробуйтеправильный размерваши виртуальные машины. Я почти уверен, что большинство из них могут работать с 2 vCPU. Добавление виртуальных CPU не заставляет все работать быстрее, так что если это средство от проблемы производительности, то это неправильный подход.
В большинстве сред ОЗУ является наиболее ограниченным ресурсом. Но ЦП может быть проблемой, если слишком много конкуренции. У вас есть доказательства этого. ОЗУ также может быть проблемой, еслислишком много выделено отдельным виртуальным машинам.
Это можно отслеживать. Метрика, которую вы ищете, — «CPU Ready %». Вы можете получить к ней доступ из клиента vSphere, выбрав виртуальную машину и перейдя в Performance> Overview> CPU Graph.
- Менее 5% готовности ЦП- Все в порядке.
- 5-10% готовности ЦП- Внимательно следите за активностью.
- Более 10% готовности ЦП- Не хорошо.
Обратите внимание на желтую линию на графике ниже.
Не могли бы вы проверить это на проблемных виртуальных машинах и сообщить о результатах?
решение2
В комментариях вы пишете, что у вас есть хост ESXi с двумя четырехъядерными процессорами и вы используете одну виртуальную машину с 8 vCPU, ичетырнадцатьВиртуальные машины 4vCPU.
Если бы это было мое окружение, я бы считал этогрубоизбыточно выделено. Я бы максимум разместил на этом оборудовании от четырех до шести гостевых систем с 4vCPU. (Это предполагает, что рассматриваемые виртуальные машины имеют нагрузку, требующую от них такого большого количества vCPU.)
Я предполагаю, что вы не знаете золотого правила... с VMware вы никогда не должны назначать виртуальной машине больше ядер, чем ей нужно. Причина? VMware использует довольно строгое совместное планирование, которое затрудняет получение виртуальными машинами процессорного времени, если только не доступно столько ядер, сколько назначено виртуальной машине. Это означает, что виртуальная машина 4vCPU не может выполнить 1 единицу работы, если в один и тот же момент не открыто 4 физических ядра. Другими словами, с точки зрения архитектуры лучше иметь виртуальную машину 1vCPU с 90% загрузкой процессора, чем виртуальную машину 2vCPU с 45% загрузкой на ядро.
Итак... ВСЕГДА создавайте виртуальные машины с минимальным количеством виртуальных ЦП и добавляйте их только тогда, когда это действительно необходимо.
В вашей ситуации используйте Veeam для мониторинга использования ЦП на гостевых системах. Уменьшите количество vCPU на максимально возможном количестве. Я готов поспорить, что вы сможете снизить количество vCPU до 2vCPU почти на всех ваших существующих гостевых системах с 4vCPU.
Конечно, если все эти виртуальные машины действительно имеют достаточную загрузку ЦП, чтобы потребовать имеющегося у них количества виртуальных ЦП, то вам просто нужно будет купить дополнительное оборудование.
решение3
127 835,94 миллисекунды — это сумма, и вам нужно разделить ее на время выборки, чтобы получить правильные значения %RDY. Похоже, что вы уже получаете правильные показания %RDY. Вы можете зайти довольно высоко с соотношением vCPU к физическому процессору, но не так, как вы это делаете.
У вас слишком много виртуальных машин с четырьмя vCPU и даже одна виртуальная машина с восемью vCPU. Уже есть несколько качественных ответов, в которых обсуждается правильный размер и некоторые последствия отсутствия объединения циклов в меньшее количество vCPU. Единственное, что я хотел бы прояснить, это то, что, хотя больше не требуется, чтобы виртуальная машина ждала, пока количество физических процессоров, равное количеству ее vCPU, станет доступным, прежде чем можно будет обработать любую инструкцию, очень вредно иметь избыточное выделение ресурсов такого масштаба с соотношением виртуальных машин с несколькими vCPU и физическими ядрами. 64 vCPU на 8 ядрах намного превышают максимальное соотношение 4 к 1. Я предполагаю, что у вас есть HT на этих процессорах, поэтому у вас 16 логических ядер? Это может быть нормально для виртуальных машин с одним и двумя vCPU, которые имеют небольшую нагрузку, но если у вас большая нагрузка на виртуальные машины, этого будет трудно достичь.
FYI Процессоры HT не используются в расчетах использования CPU % - то есть, если у вас есть 32 логических ядра, работающих на частоте 2,4 ГГц на сервере, вы находитесь на 100% использовании, когда достигаете 38,4 ГГц. Так что, когда вы видите, что средние значения нагрузки показывают больше 1,0, вот почему.
Вот хост ESXi, на котором соотношение виртуальных ЦП к физическим ЦП (включая ядра HT) составляет 3,5:1 со средним %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
......
решение4
С тех пор мы установили Veeam ONE, который пролил свет на то, где у нас проблемы с производительностью. Глядя на экран CPU Bottlenecks в Veeam ONE, а затем используяУстранение неполадок виртуальной машины, которая перестала отвечать: сравнение использования VMM и гостевого ЦПДля справки мы выяснили, где находится большая часть наших «неприемлемых» утверждений.
Один небольшой совет, которым я хотел поделиться, заключается в том, что в одном случае я не смог устранить конфликт ЦП, пока не удалил снимок, который был на ВМ. Надеюсь, это кому-то поможет.