Назад | Перейти на главную страницу

Как спрогнозировать / измерить ожидание физического хоста с многоядерными гостями в ESXi

Я слышал, что если у вас есть гость с N виртуальными ядрами под ESXi, гипервизор ожидает, пока N общих логических процессоров на хосте станут доступны одновременно, прежде чем делегировать работу с гостя на оборудование. Поэтому советуем вам очень внимательно подумать об увеличении числа гостевых ядер на X, если вам действительно не нужны циклы обработки, потому что вы столкнетесь с увеличением этого ожидания пропорционально X, и вы хотите, чтобы ваш выигрыш от добавления vcpus перевешивал стоимость этой увеличенной задержки.

В крайнем примере предположим, что хосты ESXi hA и hB имеют идентичное оборудование и конфигурации, и каждый из них имеет одного гостя (gA и gB соответственно), а гости идентичны, за исключением того факта, что gA имеет 1 виртуальный процессор, а gB - 2. Если вы поместите одинаковую (непараллелизируемую) рабочую нагрузку на оба хоста, gA «должен» выполнять задачу «быстрее».

  1. Эта задержка ожидания процесса реальна? Подтверждается документацией VMWare?
  2. Если это реально (и не очевидно из предоставленной документации), существуют ли уравнения для измерения прогнозируемого влияния увеличения гостевых виртуальных ЦП заранее? Инструменты для измерения того, какое влияние на реальный мир уже оказывает задержка?

—- Если это вообще актуально, реальная проблема, порождающая этот вопрос, заключается в том, что у нас есть MS SQL Server 2014 с 4 ядрами, которые работают в среднем на 60% мощности в течение дня с регулярными скачками до 100%, и у нас есть внутренние дебаты относительно того, разумно ли увеличить количество ядер до 6 или 8, чтобы облегчить некоторые проблемы с производительностью, с которыми мы сталкиваемся. Хост имеет (я не знаю модель, только спецификации) двухпроцессорный Intel hexcore с тактовой частотой 2,6 ГГц с гиперпоточностью - так что 24 логических ядра на хост.

Есть много плохих советов VMware и несуществующих передовых практик.

Даже веб-сайт VMware продвигает устаревшие решения из-за плохого SEO.

Но право способ оценить это - использовать такой инструмент, как vSphere Realize Operations Manager (vROP) чтобы получить рекомендацию по размеру, основанную на вашей реальной активности.

В противном случае просто увеличьте и проверьте удар. Перейдите к 5 vCPU и измерьте. Потом 6 vCPU ... и т. Д.

Кроме того, прочтите одну из книг «Технические подробные погружения», чтобы лучше понять распределение ресурсов: https://www.amazon.com/gp/product/1540873064


Пример:

Гиперпоточность - это ложь о количестве ядер, которое нужно увеличить на несколько процентов. У вас нет 24 ядер, у вас есть 12. Хотя, мне было бы немного лучше, если бы я полностью использовал эти 12 ядер для гостей с гиперпоточностью.

Когда гость пересекает размер узла, у вас будут эффекты NUMA при доступе к удаленным ЦП или ОЗУ. Для этих шестиядерных сокетов определенно vCPU 8. Это также применимо к операционным системам на физическом сервере без гипервизора. Вероятно, управляемый, учитывая, что ESXi и MS SQL стали намного больше. Просто знайте, что есть убывающая отдача.

Строгий совместное планирование, при котором все vCPU виртуальной машины останавливаются, если есть перекос в расписании, не использовался с ESX 2. Упрощенное совместное планирование больше зависит от количества виртуальных ЦП. Вы можете измерить, достигают ли процессоры большего прогресса, чем другие, с помощью % CSTP в esxtop.

Независимо от планировщика, для максимальной пропускной способности и минимальной задержки не превышайте количество виртуальных ЦП. Эти двойные шестнадцатеричные ядра получают гостей в сумме 12 vCPU. Нет никакого ожидания простоя процессора, когда у вас фактически есть выделенный для гостя.