Лучшая практика: виртуальные ЦП на физическое ядро


27

Я пытаюсь найти некоторую документацию или руководства по лучшей практике для виртуализации в отношении предоставления виртуальных ЦП для каждого физического ядра (ЦП). Если это имеет значение, я смотрю на vmWare для реализации виртуализации. Например, процессор Intel Xeon может иметь 4, 8 и т. Д. Ядра. Я заинтересован в том, чтобы узнать больше о выделении ресурсов, кроме одного vCPU на одно физическое ядро. Поставщик, с которым я разговариваю, определенно считает, что одно ядро ​​можно выделить в несколько виртуальных ЦП.

До сих пор я обычно вижу в своих исследованиях: «Ну, это зависит от вашей заявки». И в этом случае мое приложение редактирует код, компилирует / связывает, тестирует и управляет конфигурацией. Конечно, не все виртуальные машины должны быть настроены с несколькими виртуальными ЦП на ядро, но в общем случае.

Ответы:


24

Один физический процессор может использовать столько же виртуальных процессоров. Вы редко исчерпываете ресурсы процессора в решениях для виртуализации. ОЗУ и память всегда являются ограничивающими факторами ...

Помните, что в VMware загрузка ЦП представлена ​​в используемых МГц, а не в ядрах ... Если вы не привязываете все свои виртуальные ЦП на 100% ВСЕ ВРЕМЯ , я не думаю, что ваш поставщик прав.

Давайте посмотрим на следующий кластер систем ...

  • 9 хостов ESXi.
  • 160 виртуальных машин
  • 104 физических ядра процессора по всему кластеру.
  • Средний профиль виртуальной машины: 4 vCPU и 4–18 ГБ ОЗУ.
  • ЦП можно безопасно переподписать ... но помните, он также может быть ограничен, зарезервирован и расставлен по приоритетам на уровне виртуальной машины.

введите описание изображения здесь введите описание изображения здесь

из другого активного кластера - 3 хоста 42 виртуальных машины введите описание изображения здесь


4
После просмотра 3936 миграций vMotion, я не чувствую себя слишком плохо из-за наших 1200
Марк Хендерсон

2
Вчера я смотрел статистику по нашему кластеру виртуальных машин, которая подтверждает данные, полученные @ewwhite. У нас 3 хоста, всего 24 процессора и 55 ГГц. У нас есть 59 виртуальных машин с 79 выделенными виртуальными ЦП. Согласно статистическим данным vSphere, за последние 6 месяцев мы в среднем использовали чуть более 14 ГГц (минимум 9 ГГц, максимум 25 ГГц), и за это время было 0 конфликтов процессора.
Пол Гир

7

Чтобы расширить возможности записи ewwhite, если у вас нет приложений, которые могут явно использовать преимущества нескольких vCPU или нескольких ядер на vCPU, абсолютно нулевое преимущество в распределении нескольких vCPU / ядер для виртуальной машины. Фактически, чаще всего вы фактически будете иметь более низкую производительность, а не работать на одном виртуальном ЦП, которому назначено одно ядро, частично из-за накладных расходов планирования, необходимых для запуска нескольких виртуальных ЦП.

FWIW, в настройке VDI часто цитируемое число составляет 5 виртуальных ЦП на физическое ядро. Конечно, это принимает во внимание рабочие столы офиса. Если ваши виртуальные машины все время заняты компиляцией кода, вы не сможете разместить 5 виртуальных ЦП на физическое ядро.

Причина, по которой так много людей говорят, что «это зависит», заключается в том, что это действительно так. Посмотрите на значения CPU Ready и затем решите, сможете ли вы увеличить нагрузку на CPU в конкретной системе. CPU Ready - это показатель готовности виртуального ЦП к выполнению команды, но он должен ждать, пока физическое время ЦП не станет доступным.

В вашем случае, если вы компилируете большие программы, вполне возможно, что вашим виртуальным машинам действительно потребуется много процессорного времени. Как уже отмечалось, обычно виртуализация, как правило, ограничивается дисковым вводом-выводом и ОЗУ, а не ЦП.


13
absolutely zero benefit in allocating multiple vCPUs/cores to a VM- не совсем правильно. У нас есть однопоточное приложение, которое еженедельно зависало. Когда один vCPU был на 100%, было невозможно войти в эту систему, и нам пришлось выполнить сброс виртуальной машины на уровне гипервизора. Мы добавили второй vCPU, и когда приложение зависло, мы смогли легко войти и уничтожить нарушающий поток. Это немного правдоподобный случай, но вы никогда не можете иметь дело с абсолютами.
Марк Хендерсон

4
Марк написал причину, по которой мы используем два ядра в качестве нижнего предела для каждой виртуальной машины - независимо от того, нужна она им или нет.
Нильс

2
Значение готовности - это лучший способ узнать, если вы чрезмерно выделяете хост, значение готовности должно быть как можно ниже. Это% времени, в течение которого виртуальная машина «готова» использовать цикл ЦП, но должна ждать, пока ЦП занят другой задачей. Чтобы объяснить, почему предоставление многим ядрам виртуальной машины может повлиять на производительность, я приведу простой пример: если у меня 4 физических ядра и 4 виртуальных машины, если у вас есть 3 виртуальные машины с 2 ядрами и одна виртуальная машина с 4 ядрами, ваши меньшие виртуальные машины будут фактически получать больше циклов, так как они могут «вписаться» лучше в кратные. Иди как можно более консервативно с тобой vcpus!
Ркомей

@MarkHenderson Я вижу, как это может быть полезно, и что-то подобное может произойти с парнем, который задал вопрос, так как он работает с компиляторами.
Экстрактор реальности

@ Nils Я считаю, что давать каждой виртуальной машине 2 ядра независимо от того, нужна ли она бизнесу или нет, это действительно плохая идея. Это может легко негативно повлиять на вас во многих отношениях: размер слота, недостаточно ядер, доступных для перезапуска / восстановления после сбоя, потеря производительности из-за того, что написал Rqomey, просто бесчисленное множество других вещей. Вы всегда можете войти в свою виртуальную машину через vCenter и DCUI.
Экстрактор реальности

3

Основная проблема в основном та же, что и при планировании процессов в физической системе. Пока загрузка системы ниже количества ядер (или даже логических процессоров, в случае HyperThreading), все в порядке, и процессоры могут справиться с нагрузкой.

Поэтому до тех пор, пока одновременная нагрузка на все используемые виртуальные ЦП не превышает нагрузку, которую могут обрабатывать ваши физические ядра, все в порядке.

Для ваших требований только компиляция является трудоемкой работой процессора, которая требуется только время от времени. Для виртуальных машин компилятора мы выделяем столько процессоров, сколько доступно. Так что, если есть необходимость компиляции, это будет сделано как можно быстрее (если ваш компилятор поддерживает компиляцию paralell).

Это может быть не так для виртуальной машины компилятора, которая находится под постоянной нагрузкой (например, если вы предоставляете интернет-сервис для компиляции и который постоянно используется).


2

Одно практическое правило, которое я видел (возможно, в документации VMware), заключается в том, чтобы не выделять виртуальной машине больше ядер, чем физически существует на хосте, потому что это приведет к эмуляции нескольких vCores на одном ядре, добавляя ненужные накладные расходы.


1
Как насчет обратного? Что если у меня 6-ядерный Xeon и я выделю только 4 ядра в виртуальной машине? Каким будет представление тогда? Сможет ли система VM собирать энергию со всех 6 физических ядер или она будет ограничена четырьмя?
Сверхразум

Если вы дадите ему только 4 ядра, он будет иметь доступ только к 4 ядрам одновременно. Но я понимаю (не подтверждено), что эти 4 виртуальных ядра могут быть размещены на любых 4 из 6 физических ядер, если вы не настроили закрепление.
Пол Гир
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.