VirtualBox: плохая идея назначать больше ядер виртуального процессора, чем количество физических ядер процессора

41

Интересно, поскольку у меня есть процессор с поддержкой Hyper-Threading , плохая идея - назначать больше ядер виртуального процессора, чем число физических ядер процессора, о чем свидетельствует следующее предупреждение:

Предупреждение VirtualBox

Стенограмма:

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

Может кто-нибудь поставить рассуждения на эту тему?

EDIT1:

Рассматриваемый процессор - Intel Core i7-4700HQ, Ark Intel , CPU Benchmark

EDIT2:

Предположим, что не существует устаревшего HW, такого как HDD (вместо SSD) и / или Low RAM (здесь 16 ГБ, минимум vm.swappiness, 4 ГБ для этой ВМ) и так далее.

LinuxSecurityFreak
источник
2
Предупреждение является достаточно точным и не должно игнорироваться, если производительность в реальном времени не важна или если на виртуальную машину будет загружена только минимальная (программная) нагрузка. Смотрите. Что такое логические ядра процессора (в отличие от физических ядер процессора)?
АРУ
Как говорит Варинг. На самом деле все может быть быстрее с меньшим количеством процессоров в виртуальной машине.
Руи Ф Рибейру
Вы никогда не должны идти в красную линию. Можно использовать 4 «ядра» на 4-х ядерных процессорах с поддержкой HT. Что касается ОЗУ, 50% вашей ОЗУ должно быть, даже если зеленая часть находится за этим.
Цилгалад
В Virtualbox «ядрами» являются все потоки, поэтому, если у вас есть ЦП с 4 ядрами и Hyperthreading, это похоже на 8 «ядер», так что вы можете фактически настроить до 4 виртуальных ядер в одной ВМ, если вы запускаете ее отдельно; это то, что я делаю все время, и это прекрасно работает.
цилиндр
Что я должен доказать? Красная линия - для меня более 4 «ядер», я никогда не захожу и никогда не запускаю 2 виртуальные машины одновременно. Если вы предпочитаете риск сбоя вашего ПК, отдавая весь процессор виртуальной машине, и вы ничего не делаете вне виртуальной машины, это может быть в порядке.
цилиндр

Ответы:

30

Оборудование / ОС / Программное обеспечение

Хост : Linux Mint 18 Cinnamon 64-bit (полностью обновлен); Версия ядра 4.4.0-47-generic

Гость : Windows 8.1 Pro 64-bit (полностью обновлено)

Процессор : Intel Core i7-4700HQ , (6 МБ кэш-памяти, 4 физических ядра или 8 с использованием Hyper-Threading), CPU Benchmark

VirtualBox : версия 5.1.10 r112026 (Qt5.5.1)

Гостевые дополнения : установлены и обновлены

Benchmark Tool # 1 : финальная 64-битная версия WinRAR 5.40

Benchmark Tool # 2 : финальная 64-битная версия VeraCrypt 1.19


подготовка

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


метод

  1. Для клонирования исходной виртуальной машины нужно иметь две одинаковые.
  2. Я имею, для второго прохода, так как отключенная перезагрузка Антивирус указал внизу этого ответа и обновил WinRAR в обоих случаях от бета-версии до финальной версии.
  3. Я сделал ту же самую Подготовку, как указано ранее.
  4. Виртуальная машина работала на переднем плане, без каких-либо других приложений, загружающих процессорное время. Я отключил все, что мог, для того, чтобы тест не подвергался влиянию.
  5. Чтобы включить потенциальное кеширование внутри или вне системы, я дважды запускал один и тот же тест. Преимущества почти нет.

Полученные результаты

WinRAR

  1. 4 ядра => 7,5 минут (чем меньше время, тем лучше)

    WinRAR с 4 ядрами включен

    WinRAR с 4 ядрами, 1,5 ГБ, обработанный за 7,5 минут.

  2. 8 ядер => 4,5 минуты (чем меньше время, тем лучше)

    WinRAR с 8 включенными ядрами

    WinRAR с 8 включенными ядрами, 1,5 ГБ обрабатывается за 4,5 минуты.


VeraCrypt

  1. 4 ядра => скорость 2,6 ГиБ / с (чем выше скорость, тем лучше)

    VeraCrypt с 4 ядрами включен

    VeraCrypt с 4- ядерным включением, HES-ускоренным AES (AES-NI) со скоростью 2,6 ГБ / с.

  2. 8 ядер => скорость 3,9 ГиБ / с (чем выше скорость, тем лучше)

    VeraCrypt с 8 ядрами включен

    VeraCrypt с 8- ядерным включением, HES-ускоренным AES (AES-NI) со скоростью 3,9 ГБ / с.


Вывод

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

Оба теста показывают заметную разницу. Я не вижу оснований полагать, что их результаты являются неточными, поскольку я следовал довольно строгой подготовке и методике, более того, эти тесты проводились в ОЗУ, чтобы исключить узкое место ввода-вывода. С моей точки зрения, предупреждение, упомянутое в вопросе, может относиться к некоторым условиям, но, конечно, не ко всем. Поделившись с вами этими довольно замечательными результатами, я уверен, что вы согласитесь со мной, что это предупреждение, вероятно, не следует воспринимать так серьезно на современных процессорах с Hyper-Threading с последней версией VirtualBox. Одно можно сказать наверняка: не принимайте меня за слово и не проверяйте его в ваших собственных условиях, прежде чем вы решите применить этот параметр навсегда.

LinuxSecurityFreak
источник
Вы запускали его на одной и той же виртуальной машине с измененными ядрами или на двух разных (но идентичных) виртуальных машинах? Если это та же виртуальная машина, пытались ли вы впоследствии повторить попытку в другой последовательности, чтобы исключить возможное влияние алгоритмов кэширования гостевых ОС?
Подстановочный
Попробуй запустить настоящий тест прожига процессора для удовольствия.
цигалад
Что-то вроде prime95 хотя бы на час. И попробуйте одновременно просматривать веб-страницы на хосте. Как я уже сказал, это нормально, если вы ничего не делаете на хосте или не запускаете более одной виртуальной машины одновременно. Если бы это было так плохо, ограничение было бы введено в Virtualbox вместо предупреждения.
цилиндр
Вы можете попробовать еще одну вещь, но это может быть сложнее. Установите gentoo или Linux с нуля VM и проверьте, как идут дела, когда он интенсивно компилируется. Или попробуйте собрать Chromium в виртуальной машине.
цилиндр
@Vlastimil полностью согласен. В моем случае я использую VM для компиляции C ++ (которая связана с процессором), и единственная причина, по которой я получил 16-ядерный процессор, состояла в том, чтобы иметь возможность быстрее компилировать. Это предупреждение - полная чепуха без надлежащего объяснения и приводит к таким ошибочным выводам, как «Все могло бы быть на самом деле быстрее при меньшем количестве процессоров в ВМ»
Павел P
16

Как разработчик ОС, я полностью согласен с результатами измерений. Количество ерунды, произведенной в другом месте о предмете, невероятно.

Посмотрите количество логических ядер как число параллельных потоков / процессов, которые могут быть выполнены HW. Это достигается путем дублирования, например, регистров и указателей команд ядра ЦП. Теперь само ядро ​​процессора решает, какой поток (указатель инструкции) использовать. Он решит использовать другой поток, поскольку инструкция текущего потока недоступна в кеше и должна быть выбрана, например, из памяти или кеша L3. Этот механизм создаст 10% -30% потенциальное улучшение команд / секунд или производительности процессора.

Если вы запустите одно приложение с одним потоком, вы не сможете воспользоваться этим преимуществом, но если вы запустите два приложения с высокой нагрузкой, например, на старом HT Pentium, вы сможете воспользоваться преимуществами. То же самое верно, конечно, для приложений, которые имеют более одного потока. Моя система Linux имеет 200 потоков, поэтому всегда присутствуют некоторые преимущества, зависящие от фактической нагрузки. Все эти замечания применимы без виртуализации.

Virtualbox ограничивает только количество потоков, которые могут работать параллельно для каждой виртуальной машины (ВМ), но планировщик хост-процессов изменит логический процессор (-ы) и, следовательно, физический процессор (-ы), на которых процессы ВМ работают динамически. Если вы запускаете приложения с высокой нагрузкой на ВМ, дополнительные логические ядра дадут вам то же преимущество в 10% -30%. Загрузка может представлять собой одно многопоточное приложение или набор различных приложений.

В современных системах с VT-x или AMD-V нет снижения производительности при увеличении количества логических ядер, поскольку также не наблюдается заметного снижения производительности при одновременном запуске большего количества виртуальных машин. Ваш предел - это производительность вашего процессора, поэтому вы не можете воспроизводить видео на 3 виртуальных машинах одновременно, не замедляя каждую виртуальную машину, потому что они должны использовать один и тот же физический процессор.

Ваша хост-система может перестать отвечать на запросы, если вы рендерите видео на ВМ со всеми присутствующими логическими ядрами, но у вас будет почти такая же проблема, если вы запустите это приложение рендеринга на вашем хосте. По крайней мере, в VM у вас есть выбор, и вы можете решить его, ограничив максимальную загрузку ЦП до 80% -90% или уменьшив количество ядер по этой причине.

Берт Нийхоф
источник
0

Мои лучшие два цента - никогда не использовать все ядра / потоки, просто один или два для хоста.

Так что в вашем случае дайте гостю шесть ядер, а не восьмое ядро ​​(потому что у вас только 8 потоков на хосте).

Если количество доступных потоков (не путать с ядрами) на хосте равно:

  • Если <2, лучше вообще не использовать виртуальные машины
  • Если 2, используйте виртуальные машины в одноядерном режиме или рискуйте и используйте двухъядерный гостевой
  • Если> 2, лучше использовать формулу

Для более чем двух потоков я склонен использовать эту формулу:

  • N = номер потока для хоста
  • M = количество одновременно работающих виртуальных машин, которые я хочу запустить (при условии равного баланса, одинакового количества гостевых ядер для каждого гостя)
  • Формула = (N-1) / M, если в хосте только 4 потока или меньше
  • Формула = (N-2) / M, если хост имеет более 4 потоков

Мой опыт подсказывает мне, что гораздо более плавно и менее рискованно не превышать такой предел формулы.

Предупреждение: Не разрешается изменять количество гостевых ядер при работе гостя, но разрешено снижать загрузку ЦП со 100% до 75% или также на 50%, не менее гостевая система может потерпеть неудачу.

Так что иногда я склонен отдавать двум гостям по 6 ядер на 8-поточном хосте (число в формуле, как будто только один гость вместо двух гостей), но ограничив их до 50% скорости процессора (чтобы оба гостя могли использовать 1 / 2 времени процессора), но только тогда, когда я знаю, что гости будут запускать приложения с параллельным отношением больше одного, как, например, сравнение / объединение изображений и т. Д.

Лаура
источник
1
Вы сами сделали эти формулы? Или вы можете добавить цитаты?
LinuxSecurityFreak