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