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

Действительно ли установка виртуальной машины с более чем 1 процессором на ядро ​​улучшит производительность?

Когда я использую рабочую станцию ​​VMware, я могу установить виртуальную машину с несколькими ядрами. На самом деле я использую его на машине с двухъядерным и 4 логическими ядрами. Так действительно ли я мог бы улучшить производительность VMS, используя больше ядер на виртуальной машине?

это зависит от того, на чем работает виртуальная машина, гость на машине с числом ядер n будет лучше всего работать с назначенными ядрами n-1, если гость может эффективно использовать несколько процессоров. К сожалению, самый простой способ определить это - попробовать и посмотреть. Я обычно начинаю с 2 и прекращаю, когда у меня заканчивается прирост производительности. Обычно я вижу «золотую середину» - это 2 ядра. Несколько комбинаций приложений и ОС, которые я встречал, масштабируются лучше, чем это.

Чтобы уточнить, вы говорите, что у вас двухъядерный процессор, и вы назначили 4 виртуальных процессора на виртуальную машину?

В этом случае нет; если вы назначите больше виртуальных ЦП, чем у вас есть физических ядер выполнения, вы фактически увидите небольшое снижение производительности из-за накладных расходов на совместное использование 2 физических ядер между 4 виртуальными ядрами (плюс все, что работает на физическом хосте).

Вы увидите лучшую производительность виртуальной машины, назначив ей 2 виртуальных ЦП.

Некоторое время назад мы экспериментировали (см. мой вопрос год назад) с назначением виртуальных ЦП из физических ядер по сравнению с логическими ядрами (потоками) в четырехъядерных ЦП с гиперпоточностью (оказалось, что доступно 8 назначаемых виртуальных ЦП). В ответах, которые я получил тогда, было высказано предположение - и наш опыт подтвердился - вам следует выделить минимальное количество ядер, которое вы можете для каждого гостя, чтобы он мог работать.

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

Как тогда сказал @Chris S в своем комментарии, «всегда выделяйте как можно меньше, и вы избежите больших головных болей».