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

Стенограма:

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

Чи може хтось викласти міркування на цю тему?

EDIT1:

Процесор, про який йдеться, - це Intel Core i7-4700HQ, Ark Intel , CPU Benchmark

EDIT2:

Припустимо, немає застарілого HW, як-от HDD (замість SSD) та / або низької оперативної пам’яті (тут 16 Гб, мінімум vm.swappiness, 4 Гб для цього ВМ) тощо.

Обладнання / ОС / Програмне забезпечення

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

Гість : Windows 8.1 Pro 64-розрядний (повністю оновлений)

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

VirtualBox : Версія 5.1.10 r112026 (Qt5.5.1)

Доповнення для гостей : Встановлено та оновлено

Інструмент Benchmark №1 : 64-розрядна 64-розрядна версія WinRAR версії 5.40

Інструмент Benchmark №2 : 64-розрядна версія 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 ядрами, швидкістю AW (AES-NI) з прискореним HW швидкістю 2,6 ГБ / с.

2. 8 ядер => швидкість 3,9 Гб / с ( більша швидкість)

   

   VeraCrypt з увімкненими 8 ядрами, AES (AES-NI) з прискореним HW швидкістю 3,9 Гб / с.

Висновок

Я міг би провести стільки тестів, скільки потрібно. Але я вважаю, що якщо ці два, один з яких є досить складним тестом на стиснення, другий - це набір досить складних тестів шифрування, який би був сенс.

Обидва показники показують помітну різницю. Я не бачу причин вважати, що їх результати є неточними, оскільки я дотримувався досить жорсткої підготовки та методу, до того ж ці тести проходили в оперативній пам’яті, щоб виключити вузьке місце вводу / виводу. З моєї точки зору, попередження, згадане у питанні, може стосуватися деяких умов, але, безумовно, не для всіх. Поділившись із вами цими чудовими результатами, я впевнений, що ви погоджуєтесь зі мною, що це попередження, мабуть, не слід сприймати так серйозно на сучасних процесорах, що містять Hyper-Threading з останньою версією VirtualBox. Одне напевно: Не сприймайте мене за слово і не перевіряйте його у власних умовах, перш ніж ви вирішите застосувати цей параметр назавжди.

Як дизайнер ОС я повністю згоден з результатами вимірювань. Кількість дурнів, вироблених в іншому місці з цього приводу, неймовірна.

Дивіться кількість логічних ядер як кількість паралельних потоків / процесів, які можуть виконувати HW. Це досягається шляхом дублювання, наприклад, регістрів та покажчиків інструкцій ядра процесора. Тепер ядро ​​CPU вирішує, який потік (покажчик інструкції) використовувати. Він вирішить використовувати інший потік, оскільки інструкція поточного потоку недоступна в кеш-пам'яті і потребує отримання, наприклад, з кеш-пам'яті або L3-кеша. Цей механізм створить 10% -30% потенційного поліпшення інструкцій / секунд або продуктивності процесора.

Якщо ви запустили одну програму одним потоком, ви не зможете скористатися цією перевагою, але якщо запустити два додатки з високим навантаженням, наприклад, на старому HT Pentium, ви зможете скористатися перевагами. Те ж саме стосується програм, у яких більше одного потоку. Моя система Linux має 200 потоків, тому деякі переваги, залежні від фактичного навантаження, завжди є. Усі ці зауваження застосовуються без віртуалізації.

Virtualbox обмежує лише кількість потоків, які можуть працювати паралельно для кожної віртуальної машини (VM), але планувальник хост-процесів змінить логічні (-і) процесори (s) і, таким чином, фізичні (-і) процесори, на яких процеси VM динамічно запускаються. Якщо ви запускаєте додатки з високим навантаженням на VM, додаткові логічні ядра дадуть вам таку ж користь у 10% -30%. Навантаження може представляти собою один багатопотоковий додаток або набір різних застосувань.

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

Ваша хост-система може стати безвідповідальною, якщо ви рендеруєте відео на VM з усіма присутніми логічними ядрами, але у вас виникне майже однакова проблема, якби ви запустили цю програму візуалізації на своєму хості. Принаймні, у 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 часу процесора), але лише тоді, коли я знаю, що гості запускають додатки, які мають більше, ніж одне співвідношення паралельних, як-от із зображенням порівняння / об'єднання тощо.