CPU Ready - это то, с чем вы, возможно, не знакомы. На первый взгляд, это может показаться хорошим, но, к сожалению, это не так. CPU Ready преследовал виртуальные среды дольше, чем мы предполагали. VMware определяет это как «процент времени, в течение которого виртуальная машина была готова, но не могла быть запланирована для запуска на физическом процессоре». Время готовности ЦП зависит от количества виртуальных машин на хосте и их загрузки ЦП ». Hyper-V только недавно начал предоставлять этот счетчик (Виртуальный процессор гипервизора Hyper-V Время ожидания ЦП на отправку), а другие гипервизоры могут по-прежнему не предоставлять эту метрику.
Чтобы понять, что такое CPU Ready, нам нужно понять, как гипервизоры распределяют виртуальные ЦП (vCPU) на физические ЦП (pCPU). Когда в виртуальной машине требуется время vCPU, необходимо запланировать использование vCPU для pCPU (ов), чтобы команды / процессы / потоки могли работать с pCPU. В идеальном мире нет конфликтов ресурсов или узких мест, когда это необходимо. Когда одной виртуальной машине vCPU необходимо запланировать время для pCPU, доступно ядро pCPU, а готовность процессора очень минимальна в этом идеальном мире. Важно отметить, что CPU Ready всегда существует, но в идеальном мире он минимален и незамечен.
В реальном мире одним из преимуществ виртуализации является то, что вы можете поспорить, что многие из ваших виртуальных машин не будут загружать все свои виртуальные ЦП одновременно, а если они очень мало используются, вы даже можете предположить, сколько вы можете загрузите свой физический хост в зависимости от использования ЦП и ОЗУ. В прошлом давались рекомендации иметь соотношение 4 vCPU к 1 pCPU или даже соотношение 10: 1 в зависимости от рабочей нагрузки. Например, у вас может быть один четырехъядерный процессор, но у вас есть 4 виртуальных машины с виртуальными ЦП каждая, что дает вам 16 виртуальных ЦП на 4 процессора или 4: 1. Однако инженеры начали понимать, что окружающая среда была ужасно медленной, и они не могли понять, почему. Использование ОЗУ казалось нормальным, использование ЦП на физических хостах может быть даже очень низким, менее 20%. Задержка хранилища была чрезвычайно низкой, но виртуальные машины работали крайне медленно.
То, что происходило в этом сценарии, было CPU Ready. Очередь виртуальных ЦП, готовых к планированию, накапливалась, но не было доступных для планирования pCPU. Гипервизор остановит планирование и вызовет задержку для гостевой виртуальной машины. Это тихий убийца, который до недавнего времени было не так много инструментов для обнаружения. На виртуальной машине Windows загрузка займет целую вечность, а затем, когда она наконец загрузится, когда вы нажмете на меню «Пуск», это займет целую вечность, чтобы появиться. Вы можете даже щелкнуть его еще раз, думая, что он не принял ваш первый щелчок, а когда он, наконец, настигнет вас, вы получите двойной щелчок. В Linux ваша виртуальная машина может загружаться в режиме только для чтения или даже переключать файловые системы в режим только для чтения в какой-то момент позже.
Так как же бороться с готовностью процессора? Есть несколько способов помочь. Во-первых, это мониторинг показателей готовности процессора. В VMware не рекомендуется превышать 10%, но по личному опыту пользователи начинают замечать выше 5-7% в зависимости от типа виртуальной машины и того, что на ней запущено.
Ниже я буду использовать несколько примеров из VMware ESXi 5.5, чтобы показать готовность процессора. Используя командную строку, запустите «esxtop». Нажмите «c» для просмотра CPU, и вы должны увидеть столбец « % RDY ”Для CPU Ready. Вы можете нажать заглавную букву « V »Для просмотра только ВМ.
Здесь вы можете видеть, что% RDY несколько велико для довольно неиспользуемой среды. В этом случае мой ESXi 5.5 запускает тестовую виртуальную машину поверх VMware Fusion (гипервизор Mac), поэтому ожидается, что она будет немного высокопроизводительной, поскольку мы запускаем виртуальную машину на гипервизоре поверх другого гипервизора.
В клиенте vSphere вы можете вызвать конкретную виртуальную машину и щелкнуть вкладку «Производительность». Оттуда нажмите «Параметры диаграммы».
В параметрах диаграммы выберите CPU, Real-time (если у вас есть vCenter, у вас могут быть другие варианты синхронизации, кроме реального времени). Оттуда в счетчиках выберите «Готово». Возможно, вам придется отменить выбор другого счетчика, поскольку представление допускает только два типа данных в любой момент времени.
Вы заметите, что это значение является суммированием готовности к проценту. Вот ссылка на статью в базе знаний VMware о том, как преобразовать итоговые метрики в проценты. - https://kb.vmware.com/kb/2002181
При покупке оборудования большее количество ядер помогает снизить влияние CPU Ready. Также помогает гиперпоточность. Хотя Hyperthreading не предоставляет полноценное второе ядро для каждого основного ядра, обычно этого достаточно, чтобы разрешить планирование виртуального ЦП для pCPU и помочь смягчить проблему. Несмотря на то, что гипервизоры начинают отходить от рекомендаций по соотношению виртуальных ЦП к количественным ЦП, обычно вы можете хорошо справиться с умеренно используемой средой с соотношением 4: 1 и оттуда. Когда вы начинаете загружать виртуальные машины, посмотрите на задержку ЦП, готовность ЦП, а также общее ощущение и производительность. Если у вас есть несколько виртуальных машин, которые сильно поражаются, вы можете разделить их на другие кластеры и использовать более низкое соотношение и сделать их легкими. С другой стороны, для виртуальных машин, для которых производительность не является ключевой, и они могут работать медленно, вы можете подписаться намного выше.
Правильный выбор размера виртуальных машин также является огромным инструментом для борьбы с готовностью к процессору. Многие поставщики рекомендуют спецификации намного больше, чем то, что действительно может понадобиться виртуальной машине. Традиционно больше процессоров и больше ядер = больше мощности. Проблема в виртуальной среде заключается в том, что гипервизору приходится распределять все vCPU для pCPU примерно в одно и то же время, и блокировка pCPU может быть проблематичной. Если у вас есть виртуальная машина с 8 виртуальными ЦП, вам необходимо заблокировать 8 процессоров, чтобы они могли планировать работу одновременно. Если ваша виртуальная машина vCPU использует только 10% от общего количества vCPU в любой момент времени, вам лучше уменьшить счетчик vCPU до 2 или 4. Лучше запустить виртуальную машину на 50-80% CPU с меньшим количеством vCPU, чем 10% при больше виртуальных ЦП. Эта проблема отчасти связана с тем, что планировщик ЦП операционной системы предназначен для использования как можно большего числа ядер, тогда как если бы он был обучен максимальному использованию ядер перед использованием большего количества, это может быть меньшей проблемой. Негабаритная виртуальная машина может работать хорошо, но может быть «шумным соседом» для других виртуальных машин, поэтому обычно это процесс, в котором вам нужно пройти через все виртуальные машины в кластере, чтобы «выбрать нужный размер», чтобы увидеть некоторый прирост производительности.
Много раз вы сталкивались с CPU Ready, и было трудно начать правильное определение размера виртуальных машин или обновление до процессоров с большим количеством ядер. Если вы находитесь в такой ситуации, добавление дополнительных хостов в кластер может помочь в распределении нагрузки по большему количеству хостов. Если у вас есть хосты с большим количеством ядер / процессоров, чем у других, также может помочь привязка виртуальных машин с высоким vCPU к этим хостам с более высоким ядром. Вы хотите, чтобы на вашем физическом хосте было хотя бы такое же количество ядер, если не больше, чем у виртуальной машины, иначе будет очень медленно / сложно запланировать избыток vCPU для pCPU, поскольку они должны быть заблокированы примерно в одно и то же время .
Наконец, ваш гипервизор может поддерживать резервирование и ограничения для виртуальной машины. Иногда тезисы ставятся случайно. Агрессивные настройки на них могут привести к готовности ЦП, когда на самом деле для него доступны базовые ресурсы. Обычно лучше использовать резервирование и ограничения экономно и только тогда, когда это абсолютно необходимо. По большей части кластер правильного размера будет надлежащим образом сбалансировать ресурсы, а они обычно не нужны.
Таким образом, лучшая защита от CPU Ready - знать, что он существует, и как это проверить. Затем вы можете систематически определять лучшие шаги по снижению риска для вашей среды с учетом вышеизложенного. По большей части информация в этой статье универсально применима к любому гипервизору, хотя снимки экрана и диаграммы относятся конкретно к VMware.
5 минут на чтение
