Я слышал, что если у вас есть гость с N виртуальными ядрами под ESXi, гипервизор ожидает, пока N общих логических процессоров на хосте станут доступны одновременно, прежде чем делегировать работу с гостя на оборудование. Поэтому советуем вам очень внимательно подумать об увеличении числа гостевых ядер на X, если вам действительно не нужны циклы обработки, потому что вы столкнетесь с увеличением этого ожидания пропорционально X, и вы хотите, чтобы ваш выигрыш от добавления vcpus перевешивал стоимость этой увеличенной задержки.
В крайнем примере предположим, что хосты ESXi hA и hB имеют идентичное оборудование и конфигурации, и каждый из них имеет одного гостя (gA и gB соответственно), а гости идентичны, за исключением того факта, что gA имеет 1 виртуальный процессор, а gB - 2. Если вы поместите одинаковую (непараллелизируемую) рабочую нагрузку на оба хоста, gA «должен» выполнять задачу «быстрее».
—- Если это вообще актуально, реальная проблема, порождающая этот вопрос, заключается в том, что у нас есть 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. Нет никакого ожидания простоя процессора, когда у вас фактически есть выделенный для гостя.