Найкраща практика: vCPU на фізичне ядро

27

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

Що я зазвичай бачу в своїх дослідженнях до цих пір, це: "Ну, це залежить від вашої заявки". І в цьому випадку моя програма редагує код, компілює / зв'язує, тестує та керує конфігурацією. Звичайно, не всі VM повинні бути налаштовані з декількома vCPU на ядро, але в загальному випадку.

— Доктор Ватсон
джерело

24

Один фізичний процесор може використовувати стільки vCPU. Ви рідко втрачаєте ресурси процесора у рішеннях для віртуалізації. Оперативна пам’ять і накопичувач - це завжди обмежуючі фактори ...

Пам'ятайте, що у VMware використання процесора представлено у використаних МГц, а не в ядрах ... Якщо ви не прив'язуєте всі свої віртуальні процесори до 100% ВСЕ ЧАС , я не думаю, що ваш постачальник є правильним.

Давайте розглянемо наступний кластер систем ...

9 хостів ESXi.
160 віртуальних машин
104 фізичних ядра ЦП через кластер.
Середній профіль віртуальної машини: 4 ВППУ і 4 ГБ до 18 ГБ ОЗУ.
ЦП можна сміливо передплачувати ... але пам’ятайте, він також може бути обмеженим, зарезервованим та пріоритетним на рівні VM.

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

— ewwhite
джерело

4

Побачивши 3936 міграцій vMotion, я не відчуваю себе дуже погано щодо наших 1200

— Марк Хендерсон

2

Я вчора дивився на статистику нашого VM кластеру, яка показує цифри, подані @ewwhite. У нас є 3 хости, загалом 24 процесори і 55 ГГц. У нас є 59 ВМ із загальною сумою виділених 79 ВКП. Згідно зі статистикою vSphere, за останні 6 місяців ми в середньому використовували трохи більше 14 ГГц (хв 9 ГГц, макс. 25 ГГц), і за цей час було 0 основних процесорів.

— Пол Гір

7

Для розширення запису ewwhite, якщо у вас немає додатків, які можуть явно скористатися декількома vCPU або декількома ядрами в vCPU, абсолютно абсолютно нульова вигода при розподілі декількох vCPU / ядер на VM. Насправді, частіше за все, ви насправді закінчуєтеся нижчою продуктивністю на відміну від запуску в одному vCPU, якому призначено одне ядро, частково через накладні витрати планування, необхідні для запуску декількох vCPU.

FWIW, в налаштуваннях VDI часто цитується число становить 5 vCPU на фізичне ядро. Звичайно, це враховує робочий стіл офісу. Якщо ваші відеомагнітофони дійсно зайняті збиранням коду весь час, можливо, ви не зможете помістити 5 vCPU на фізичне ядро.

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

У вашому випадку, якщо ви збираєте великі програми, цілком можливо, що вашим віртуальним машинам фактично буде потрібно багато часу процесора. Як зазначав ewwhite, віртуалізація, як правило, має дисковий введення / виведення та оперативну пам'ять, а не обмежена процесором.

— Витяжка реальності
джерело

13

absolutely zero benefit in allocating multiple vCPUs/cores to a VM- не зовсім коректно. У нас є однопоточна програма, яка звисала щотижня. Коли один vCPU був на 100%, неможливо потрапити в цю систему, і нам довелося зробити скидання рівня гіпервізора VM. Ми додали другий vCPU, і коли додаток зависло, ми змогли легко ввійти та вбити нитку, що ображає. Це трохи правдивий випадок, але ви ніколи не можете мати справу з абсолютами.

— Марк Хендерсон

4

Те, що написав Марк, є причиною того, що ми використовуємо два ядра як нижню межу для кожного VM - незалежно від того, потрібні вони, чи ні.

— Нільс

2

Значення готовості - це найкращий спосіб визначити, якщо ви надмірно забезпечили свого хоста, ваша готова вартість повинна бути якомога нижчою. Це% часу, коли VM "готовий" до використання циклу процесора, але повинен чекати, коли процесор зайнятий іншим завданням. Щоб пояснити, чому надання вашим вим-метрам багатьох ядер може мати вплив на продуктивність, я скористаюся простим прикладом: якщо у мене 4 фізичні ядра і 4 Вм, якщо у вас є 3 ВМ з 2 ядрами і одне вм з 4 ядрами, ваші менші віртуальних машин будуть активно отримувати більше циклів, оскільки вони можуть "краще" вписатися в кратні. Ідіть максимально консервативно з собою vcpus!

— Rqomey

@MarkHenderson Я бачу, як це може бути корисним, і щось подібне може статися з хлопцем, який задав питання, оскільки він працює з компіляторами.

— Витяжка реальності

@Nils Я вважаю, що давати кожним сердечкам VM 2, чи є в цьому потреба бізнесу чи ні, це дуже погана ідея. Це може легко негативно вплинути на вас настільки багато способів, розмір слота, недостатньо ядер, доступних для перезавантаження / відмови, втрата продуктивності завдяки тому, що написав Rqomey, просто незліченна кількість інших речей. Ви можете майже завжди потрапляти у свій VM через vCenter та DCUI.

— Витяжка реальності

3

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

До тих пір, поки одночасне навантаження на всі використані vCPU не перевищує навантаження, з яким можуть працювати ваші фізичні ядра, все добре.

Для ваших вимог лише компіляція - це інтенсивна робота процесора, яка потрібна лише час від часу. Для компіляторів-віртуальних машин ми виділяємо стільки процесорів, скільки доступно. Отже, якщо є необхідність у компіляції, це буде зроблено якнайшвидше (якщо ваш компілятор підтримує компіляцію паралельних).

Це може бути невірно для компілятора-VM, який знаходиться під постійним навантаженням (наприклад, якщо ви надаєте Інтернет-сервіс для складання компіляцій, який постійно використовується).

— Нільс
джерело

2

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

— Пол Гір
джерело

1

А що з реверсом? Що робити, якщо у мене 6-ядерний Xeon і я виділяю лише 4 ядра у VM? Якою була б тоді вистава? Чи зможе система ВМ отримувати енергію з усіх 6 фізичних ядер чи обмежиться 4?

— Передумати

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

— Пол Гір