Виртуальная машина с поддержкой процессора, что это такое
Обновлено: 21.11.2024
Это редакция предыдущей записи в блоге, которую я сделал несколько лет назад на CPU Ready Time. На этот раз я разделю его на две части, первая из которых будет посвящена обзору времени готовности ЦП, способам его мониторинга и усовершенствованиям со-планировщика. Второй пост представляет собой набор таблиц, которые помогут вам быстро рассчитать время готовности процессора. Я считаю, что таблицы полезны для анализа времени готовности ЦП в различные периоды сбора данных, такие как реальное время, день, неделя, месяц и год.
Что такое время готовности процессора?
Время готовности ЦП — это показатель vSphere, который фиксирует время, в течение которого виртуальная машина готова использовать ЦП, но не может запланировать время, поскольку все ресурсы ЦП (на хосте ESX) заняты.
Виртуальные машины и улучшенное совместное планирование
Гипервизор (ядро виртуализации) очень эффективно оптимизирует планирование. На самом деле планировщик подвергался значительным изменениям с каждым основным выпуском ESX. В следующем разделе мы обсудим текущее совместное планирование и его усовершенствования.
На данный момент хорошо известно, что максимальное количество виртуальных ЦП, которое может запустить одна ВМ, составляет 64 виртуальных ЦП. Для меня эта цифра невероятно высока. В HoB мы виртуализировали рабочие нагрузки VBCA еще в версиях ESX 3 и 4, используя максимум 4 и 8 виртуальных ЦП соответственно. По нашим оценкам, 90 % рабочих нагрузок могут уместиться в конфигурации с 8 виртуальными ЦП (или меньше). В Университете Индианы мы убедились в этом на собственном опыте, когда помогали им с виртуализацией их системы OnCourse. База данных OnCourse Oracle ранее находилась в LPAR AIX Power5 с выделенными 12 ЦП. Во время пиковых нагрузок база данных Oracle потребляла 9,5 процессора. После виртуализации рабочей нагрузки и завершения нагрузочного тестирования мы определили, что рабочая нагрузка не только уместится без максимум 8 виртуальных ЦП, но и использует только от 35% до 50% ЦП. Это оставило большую масштабируемость для базы данных. Перенесемся в сегодняшний день. Максимум 64 виртуальных ЦП открывает дверь для виртуализации 95 % существующих рабочих нагрузок.
Как компании VMware удалось перейти с максимума 8 виртуальных ЦП на максимум 64 виртуальных ЦП?
Это интригующий вопрос. Наиболее актуальная общедоступная информация об этом достижении обсуждается в официальном документе VMware — Планировщик ЦП в VMware vSphere 5.1. «Расслабленный» со-планировщик был впервые представлен в ESX версии 3.0 с максимальным количеством виртуальных ЦП для одной виртуальной машины, равным 4. В этой версии инженеры VMware адаптировали модель ячейки. Клетки были назначены pCPU (физический процессор). Распространенной конфигурацией процессора во время выпуска ESX 3 был физический процессор с 4 ядрами. Поскольку число ядер pCPU увеличилось с появлением чипов AMD и Intel, VMware определила, что модель ячеек больше не соответствует требованиям
В ESX 4 инженеры VMware перешли от ограничения в 4 виртуальных ЦП к 8 виртуальным ЦП, исключив архитектуру ячеек и установив более мелкие блокировки. Это позволяло одной виртуальной машине охватывать несколько pCPU и позволяло планировать использование одного vCPU для определенной задачи. Это дает гостевой ОС возможность планировать один виртуальный ЦП для одного процесса или потока и значительно снижает накладные расходы или затраты на планирование ЦП по сравнению с предыдущей версией ESX. ESXi 5 дополнительно улучшил планирование SMP, повысив производительность приложений SMT. Этот прирост в некоторых случаях может достигать 10–30 % (см. «Что нового в производительности в VMware vSphere 5.0»). И, конечно же, новый максимум 64 ВЦП на одну ВМ увеличился по сравнению с предыдущим максимумом в 8 ВЦП.
Вот график эволюции совместного планирования:
Мониторинг времени готовности ЦП
Отслеживайте загрузку ЦП с помощью клиента vSphere или команды esxtop. Клиент vSphere предпочтительнее, поскольку он измеряет время готовности ЦП в миллисекундах. Выберите виртуальную машину и перейдите на вкладку «Производительность». Выберите «Дополнительно» > «Параметры диаграммы» > «ЦП» > «Реальное время» > «Готово».
Рисунок 1. Выберите CPU Ready в параметрах диаграммы CPU
Рисунок 2. Время готовности процессора
Рис. 3. Отслеживание времени готовности ЦП
В среднем время готовности процессора для гостевой системы составляет от 0 до 50 мс, что называется "тактовым сигналом гостевой системы". Все, что превышает 300 мс, может привести к проблемам с производительностью. В среднем приемлемо время готовности ЦП до 300 мс с максимальной отметкой 500 мс.
Показатель готовности ЦП VMware используется для определения процента времени, в течение которого виртуальная машина была готова, но не могла быть запланирована для запуска на физическом ЦП. Время готовности ЦП зависит от количества виртуальных машин на узле и загрузки их ЦП. Обычно для просмотра значений используется команда «esxtop», чтобы определить, не «перегружается» ли сервер ESXi/ESX. Этот пост называется «Что такое VMware CPU Ready», и он не означает, что он должен быть подробным. В Интернете есть и другие ресурсы, где вы, возможно, захотите поискать более глубокие объяснения.
Мы постараемся объяснить готовность ЦП для людей, которые начинают с виртуализации, поэтому, если вы опытный администратор VMware, вы можете просто пропустить этот пост.. -:).
Обычно для виртуальной машины небольшие значения времени готовности ЦП являются нормальным явлением, если гипервизор не перегружен или не находится в режиме интенсивной активности. Это связано с характером совместного планирования в виртуализации.
Виртуальные машины, настроенные с несколькими виртуальными центральными процессорами (вЦП), время готовности будет выше, чем для ВМ с меньшим количеством виртуальных ЦП, поскольку требуется больше ресурсов для планирования или совместного планирования ВМ, когда это необходимо, и каждого из виртуальных ЦП. накапливает время отдельно. (также называемая SMP-обработкой).
Симметричная многопроцессорная обработка (SMP) – это обработка программ несколькими процессорами, совместно использующими ОС и память. В симметричной многопроцессорной обработке процессоры совместно используют память и шину ввода-вывода (или, как мы говорим, путь данных). Но одна ОС управляет всеми процессорами.
Симметричная многопроцессорность (SMP) включает в себя аппаратную и программную архитектуру многопроцессорного компьютера, в которой два или более идентичных процессора подключены к одной общей основной памяти, имеют полный доступ ко всем устройствам ввода-вывода и управляются один экземпляр операционной системы, который одинаково обрабатывает все процессоры, не оставляя ни одного для специальных целей. Большинство современных многопроцессорных систем используют архитектуру SMP. В случае многоядерных процессоров архитектура SMP применяется к ядрам, рассматривая их как отдельные процессоры.
Где проверить значения CPU Ready?
Проверьте поле %READY (RDY% в esxtop), чтобы определить процент времени, в течение которого виртуальная машина была готова, но не могла быть запланирована для запуска на физическом ЦП.
В нормальных условиях эксплуатации это значение не должно превышать 5 %. Если значения времени готовности высоки на виртуальных машинах с низкой производительностью, проверьте ограничение ЦП:
- Убедитесь, что виртуальная машина не ограничена установленным ею лимитом ЦП.
- Убедитесь, что виртуальная машина не ограничена пулом ресурсов.
В какой-то момент VMware порекомендовала отслеживать все, что превышает 5 % времени готовности на виртуальный ЦП, но это было несколько лет назад….
Когда у хоста слишком много подписчиков?
Это означает, что виртуальные машины, работающие на хосте, будут работать все медленнее и медленнее. Когда слишком много vCPU выделено на соотношение pCPU. Так что это зависит.
Ваш пробег может варьироваться в зависимости от конкретных рабочих нагрузок ваших ВМ, но обычно мы можем видеть проблемы, когда хост превышает подписку в 2–2,5 раза (рабочие нагрузки сервера). VDI — это отдельная история…
Но что можно сделать?
Один из способов может состоять в том, чтобы начать с небольшой оценки того, нужно ли виртуальным машинам иметь заданное количество виртуальных ЦП. И если это так, некоторые из них можно будет перенастроить, чтобы снизить коэффициент.
DC Scope для VMware vSphere — оптимизация, планирование емкости и управление затратами. Загрузите БЕСПЛАТНУЮ пробную версию здесь.
- Отслеживает производительность ВМ с помощью сводного представления ресурсов и метрик в процессе деградации.
- Легко повышайте производительность своей инфраструктуры.
- DC Scope предлагается по доступной цене за виртуальную машину.
Если это невозможно сделать, добавьте дополнительные хосты, чтобы лучше сбалансировать нагрузку и уменьшить переподписку. Если проблема связана только с более крупными виртуальными машинами SMP, такими как виртуальные машины, такие как SQL Server, Microsoft Exchange Server, вы можете оценить, можете ли вы консолидировать эти более крупные виртуальные машины на одном или нескольких хостах и переместить меньшие виртуальные машины на другие хосты в чтобы разделить виртуальные машины в зависимости от их размера.
Инструменты для мониторинга готовности ЦП VMware?
Как уже говорилось, ESXTOP через сеанс шпатлевки — один из самых простых и быстрых способов проверить показатели готовности ЦП. Затем такие продукты, как vROP, могут стать определяющими при работе с более масштабными архитектурами.
Подведение итогов
Если вы начинаете видеть 5% или более значений, это должно быть предупреждением для вас, и вы уже можете начать испытывать снижение производительности, особенно если вы запускаете некоторые высокопроизводительные приложения в гостевой системе, такие как SQL. Сервер или сервер MS Exchange.
Автопредложение помогает быстро сузить результаты поиска, предлагая возможные совпадения по мере ввода.
- Технологическая сеть VMware
- :
- Облако и SDDC
- :
- ESXi
- :
- Обсуждения ESXi
- :
- Готовность ЦП и готовность ЦП
логиком
- Отметить как новое
- Добавить в закладки
- Подписаться
- Отключить звук
- Отправить сообщение другу
Я пытаюсь понять "Готовность ЦП" (сумма в мс) и "Готовность ЦП" (среднее значение в процентах).
Я ссылаюсь на прикрепленный скриншот. Если я посмотрю на значение в процентах, я получу 1,34% в последнем столбце готовности ЦП. Однако, если я смотрю на CPU Ready, это 1612 миллисекунд. Применение формулы:
(Суммируемое значение ЦП / ( * 1000)) * 100 = % готовности ЦП
(1612 / (20*1000)) * 100
Я ищу процент времени, в течение которого мои виртуальные машины ожидают ресурсов ЦП.
В этом примере я беру значение готовности ЦП 1,34 % или значение готовности ЦП 8,06 %?
Майк_Гелхар
- Отметить как новое
- Добавить в закладки
- Подписаться
- Отключить звук
- Отправить сообщение другу
Оба. Это виртуальная машина с одним vCPU или несколько (может быть, 6 ядер?) Один из быстрых способов проверить метрики — посмотреть ESXTOP и посмотреть значение %RDY для этой виртуальной машины. Это значение должно быть очень близко к значению «готовности», когда VMware теперь выполняет для нас математические расчеты по состоянию на vSphere 6.
VMware KB2002181 дает более простую формулу:
ЦП готов, %
В качестве упрощения вы можете использовать следующие формулы для интервалов обновления диаграммы по умолчанию, чтобы получить % готовности ЦП:
<УЛ>Пример . Суммарное значение ЦП в реальном времени, равное 1000, делится на 200, чтобы получить процент готовности ЦП, равный 5.
Предполагая, что эта ВМ имеет 6 виртуальных ЦП, остается еще один шаг. разделите значение %Ready на количество виртуальных ЦП. Для вашей многоядерной виртуальной машины формула преобразования Ready Summation в % будет следующей: (1612/200)/6=1,34
В целом это хорошо, потому что у администраторов баз данных теперь есть дополнительная информация, к которой у них не было доступа, если только они не договорились о доступе к Virtual Center со своим администратором виртуальной машины. Мой опыт консультирования показывает, что немногие администраторы баз данных имеют доступ или даже знают о Virtual Center, хотя это один из важнейших инструментов для устранения проблем с производительностью. Еще один момент, о котором не знает большинство администраторов баз данных, заключается в том, что их администратор виртуальных машин может настраивать роли и безопасный доступ только для чтения, чтобы любой мог видеть информацию о производительности и конфигурации внутри Virtual Center, но не мог вносить изменения, поэтому на самом деле у администратора баз данных нет веских причин не иметь доступа к данным о производительности, доступным в Virtual Center.
Теперь, когда у администраторов баз данных есть доступ к данным, важно знать, что отображается и что это на самом деле означает. К сожалению, способ представления информации позволяет легко неверно интерпретировать отображаемую информацию, поэтому конечным результатом является путаница для администраторов баз данных, которые мало знают о VMware или о том, что на самом деле означает информация, которую они рассматривают. Пример информации о готовности ЦП виртуальной машины из диспетчера диагностики показан на диаграмме на рис. 1.
Рис. 1. График готовности ЦП ВМ
Глядя на эту диаграмму в отчете, какой будет ваша первая интерпретация? До сих пор 3 из 3 человек, в том числе и в твиттере, думали, что проблема с этой виртуальной машиной. Реальность ситуации такова, что с этой ВМ все в порядке, все в порядке. Так уж получилось, что масштаб этого графика позволяет легко перейти к интерпретации, что он показывает процентное значение, и мы все знаем, что все, что связано с производительностью, превышающей 80%, не может быть хорошим. Об этом не говорится, но и не дается никакого контекста для значения информации. Чтобы сделать ситуацию еще более запутанной, CPU Ready в VMware доступен в виде суммирующего значения, которое показано здесь в миллисекундах, и в виде процента (RDY% в esxtop) времени, затраченного на ожидание запланированной работы. гипервизором. Мы можем подтвердить, что представленная информация представляет собой суммарное значение, а не процентное значение, просмотрев информацию в реальном времени, доступную в Virtual Center для того же сервера, как показано на диаграмме на рис. 2.
Рисунок 2. Суммирование CPU Ready в режиме реального времени из виртуального центра
Итак, теперь, когда мы знаем, что это суммирование и представлено в миллисекундах, что именно это нам говорит? К сожалению, сам по себе он ничего нам не говорит.
Что такое время готовности ЦП и зачем оно нам вообще?
Время готовности ЦП — это время, в течение которого ВМ ожидает в состоянии готовности к запуску (что означает, что у нее есть работа), чтобы быть запланированным на одном или нескольких физических ЦП гипервизором. Как правило, виртуальные машины имеют небольшие значения накопления времени готовности ЦП, даже если гипервизор не перегружен или не находится в режиме интенсивной активности, это просто природа общего планирования в виртуализации. Для ВМ SMP с несколькими виртуальными ЦП количество времени готовности, как правило, будет выше, чем для ВМ с меньшим количеством виртуальных ЦП, поскольку требуется больше ресурсов для планирования/совместного планирования ВМ, когда это необходимо, и каждый из виртуальных ЦП накапливает время отдельно.
С какого момента время готовности процессора начинает влиять на производительность?
Честно говоря, это всегда имеет минимальный эффект, но на самом деле это зависит от множества различных факторов, например, от того, какое значение CPU Ready вы просматриваете и откуда вы получаете информацию. Если вы смотрите на необработанные значения RDY% из esxtop, значение имеет совершенно другое значение, чем значения суммирования, доступные в Virtual Center. Внутри Virtual Center уровень суммирования, на который вы смотрите при чтении значений, также влияет на значение, которое имеет значение, и вам необходимо выполнить вычисления, чтобы преобразовать суммирование в процентное значение, чтобы узнать эффект, как описано в базе знаний VMware. . В этом случае для суммирования в реальном времени точкой данных фактически является 20-секундное суммирование времени готовности.
В какой-то момент компания VMware рекомендовала отслеживать все, что превышает 5 % времени готовности на виртуальный ЦП. По моему опыту, для виртуальной машины SMP SQL все, что превышает 5 % на виртуальный ЦП, обычно является уровнем предупреждения, а все, что превышает 10 % на виртуальный ЦП, является критическим. Причина, по которой здесь конкретно говорится о каждом виртуальном ЦП, заключается в том, что каждый виртуальный ЦП выделяет 100 % общего объема планирования ВМ, поэтому ВМ с 4 виртуальными ЦП будет иметь общее планирование 400 %. Готовность ЦП на 10 % на виртуальной машине с 4 виртуальными ЦП соответствует только 2,5 % на виртуальный ЦП. Если это еще не сложно, становится еще хуже.
Это делает невозможным предоставление общих рекомендаций для этого счетчика, поскольку он зависит от множества различных факторов. Например, если на виртуальной машине установлен лимит ЦП, всякий раз, когда виртуальная машина превышает выделенный лимит, она будет накапливать время готовности ЦП, пока ожидает повторного запуска. Если ограничение ЦП применяется в соответствии с бизнес-соглашениями об уровне обслуживания или системой возврата платежей, виртуальная машина может легко иметь высокие значения готовности ЦП, соответствующие требованиям конфигурации. Используя формулу из статьи базы знаний для преобразования значения суммы в проценты, если мы округлим среднее значение 81,767 до 80 для простой математики, это приведет к следующему результату:
(80 / (20 с * 1000)) * 100 = 0,4% готовности ЦП
Четыре десятых процента времени готовности ЦП, что не окажет негативного влияния на производительность ВМ. Показанному выше примеру ВМ также выделено 8 виртуальных ЦП, поэтому, приняв это во внимание, на самом деле на каждый виртуальный ЦП приходится всего 0,05 %, что намного ниже рекомендованного ранее значения.
Какие сценарии вызывают высокое время готовности ЦП?
Несмотря на то, что существует ряд сценариев, в которых может возникнуть большое время готовности ЦП, обычно есть два распространенных сценария, которые я вижу, когда консультируюсь. Наиболее распространенная причина, как правило, заключается в том, что хост превышает подписку, когда слишком много виртуальных ЦП было выделено на соотношение pCPU. Хотя ESX 5 поддерживает максимум 25 виртуальных ЦП на физический ЦП, это определенно тот случай, когда то, что вы можете, не означает, что это хорошо. Как всегда, ваш пробег может варьироваться в зависимости от ваших конкретных рабочих нагрузок ВМ, но обычно я начинаю замечать проблемы, когда хост в 2-2,5 раза превышает подписку на серверные рабочие нагрузки.
Второй распространенный сценарий, который я вижу, когда время готовности ЦП велико, — это когда более крупная виртуальная машина SMP для SQL Server, например, с 4–8 виртуальными ЦП, работает на узле, на котором есть много меньших ВМ с 1–2 vCPU для серверов приложений. В зависимости от количества физических процессоров и общего количества виртуальных ЦП, выделенных на узле, большее выделение ресурсов для виртуальной машины SQL Server приводит к тому, что гипервизору приходится дольше ждать, пока гипервизор выполнит вытеснение необходимых физических ЦП для планирования/совместного планирования. рабочая нагрузка. Часто в тех случаях, когда это происходит, задав несколько вопросов, я обнаруживаю, что количество виртуальных ЦП для SQL Server было увеличено с четырех до восьми из-за проблем с производительностью виртуальной машины. К сожалению, если исходной проблемой было время готовности ЦП, увеличение количества виртуальных ЦП на самом деле не повышает производительность, а, как правило, ухудшает ситуацию.
Что мне делать, если это действительно проблема?
Если вы ознакомились с информацией и видите, что готовность процессора действительно является проблемой для ваших виртуальных машин, есть несколько способов, которые можно предпринять. Правильный выбор зависит от вашей виртуальной инфраструктуры. Если проблема связана исключительно с отношением количества виртуальных ЦП к количеству pCPU между хостом и подпиской, начните с оценки того, нужно ли виртуальным машинам иметь такое количество настроенных виртуальных ЦП, чтобы определить, можно ли уменьшить какой-либо из них, чтобы снизить это соотношение. Если это невозможно сделать, единственный реальный ответ — добавить дополнительные хосты, чтобы лучше сбалансировать нагрузку и снизить ставки по подписке. Если проблема связана с более крупными виртуальными машинами SMP для таких приложений, как SQL Server, оцените, можно ли консолидировать более крупные виртуальные машины на одном или нескольких хостах и переместить меньшие виртуальные машины на другие хосты, чтобы разделить виртуальные машины в зависимости от их размера. Это хорошо сработало для ряда клиентов, с которыми я работал, когда им действительно требовалось восемь или более виртуальных ЦП для их рабочей нагрузки.
Обзор
Понимание данных, которые вы просматриваете, и того, что они на самом деле означают, имеет решающее значение для принятия правильных решений о том, что происходит в виртуализированной среде. Время готовности ЦП, в частности, требует хорошего понимания того, что на самом деле показывает значение и как оно связано с конфигурацией виртуальной машины, других виртуальных машин на узле и ресурсов физического узла. Если вы просматриваете данные суммирования для времени готовности ЦП, преобразование их в процентное значение готовности ЦП — это то, что обеспечивает правильное значение данных для понимания того, действительно ли это проблема. Однако имейте в виду, что другие параметры конфигурации, такие как ограничения ЦП, могут повлиять на накопленное время готовности ЦП и также должны быть проверены. Всякий раз, когда я выполняю проверку работоспособности виртуальной машины SQL Server на VMware, я получаю снимки экрана с информацией о готовности ЦП из Virtual Center для каждого из доступных уровней суммирования, чтобы я мог определить, влияет ли это на производительность. виртуальной машины, но я всегда тщательно рассчитываю, используя правильную формулу, какое процентное значение на самом деле получается, а затем просматриваю остальную часть конфигурации виртуальной машины, прежде чем делать какие-либо выводы. В худшем случае, который я видел, для одного клиента время готовности ЦП составляло примерно 63% на виртуальный ЦП, и вы могли явно видеть зависание виртуальной машины при перемещении мыши в сеансе RDP. Проверка конфигурации показала, что виртуальная машина имеет 8 виртуальных ЦП на узле с 8 физическими ЦП, на котором также работают 10 других ВМ с 14 дополнительными виртуальными ЦП. Перемещение этой виртуальной машины обратно на 2 виртуальных ЦП стало мгновенным облегчением их самого большого узкого места, а затем мы начали говорить об изменениях оборудования, чтобы соответствовать их возросшему использованию виртуализации. Если вам нужна экспертная помощь по внедрению, настройке, устранению неполадок или пониманию SQL Server на VMware, у нас есть ряд различных услуг, соответствующих вашим потребностям.
Читайте также: