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

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

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

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

EDIT1:

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

EDIT2:

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

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

Хост : 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 ядрами, 1,5 ГБ, обработанный за 7,5 минут.

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

   

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

VeraCrypt

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

   

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

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

   

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

Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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