Чи віртуальна машина повільніше, ніж основна фізична машина?

Це питання є досить загальним, але саме мене цікавить, чи віртуальна машина, що працює на Ubuntu Enterprise Cloud, буде повільніше, ніж та сама фізична машина, без віртуалізації. Скільки (1%, 5%, 10%)?

Хтось міряв різницю продуктивності веб-сервера або сервера db (віртуальний VS фізичний)?

Якщо це залежить від конфігурації, давайте уявимо два чотирьохядерні процесори, 12 ГБ пам’яті та купу SSD дисків, на яких працює 64-розрядний корпоративний сервер ubuntu. Крім того, лише 1 віртуальна машина дозволила використовувати всі доступні ресурси.

Типовий досвід роботи сервера загального призначення на чистому металі \ Hypervisor Type 1 становить приблизно 1-5% накладних витрат на процесор і 5-10% накладних витрат, з деякими додатковими накладними витратами, які змінюються залежно від загального навантаження вводу-виводу. Це в значній мірі відповідає моєму досвіду роботи сучасних гостьових ОС під управлінням VMware ESX \ ESXi, Microsoft Hyper-V та Xen, де базове обладнання було розроблено належним чином. Для 64-бітних операційних систем сервера, що працюють на апаратному забезпеченні, яке підтримує найсучасніші розширення апаратної віртуалізації процесора, я очікую, що всі гіпервізори типу 1 будуть спрямовуватися на цей 1% накладних номерів. Наразі зрілість KVM не зовсім залежить від Xen (або VMware), але я не бачу причин думати, що це буде помітно гірше за них, наприклад, описаний вами приклад.

Для конкретних випадків використання, хоча загальна \ сукупна "продуктивність" віртуального середовища може перевищувати голі метали \ дискретні сервери. Ось приклад дискусії про те, як реалізація VMware Clustered може бути швидшою \ кращою \ дешевшою, ніж голий метал OAC RAC. Методи управління пам’яттю VMware (особливо прозорий обмін сторінками) можуть повністю усунути накладні витрати на пам'ять, якщо у вас є достатня кількість подібних програм VM. Важливим у всіх цих випадках є те, що переваги продуктивності / ефективності, які може забезпечити віртуалізація, будуть реалізовані лише в тому випадку, якщо ви консолідуєте кілька VM на хости, ваш приклад (1 VM на хості) завжди буде повільніше, ніж голий метал до певної міри .

Хоча це все корисно, реальні проблеми з точки зору віртуалізації сервера, як правило, зосереджуються на управлінні, високій техніці доступності та масштабованості. Рівень продуктивності процесора на 2-5% не так важливий, як можливість ефективно масштабувати до 20, 40 або стільки ж VM вам потрібно на кожному хості. Ви можете вирішити хіт продуктивності, вибравши трохи більш швидкий процесор як базовий рівень, або додавши більше вузлів у ваші кластери, але якщо хост не може масштабувати кількість VM, він може працювати, або навколишнє середовище важко керувати або ненадійний, то його нікчемний з точки зору віртуалізації сервера.

"Продуктивність" має багато аспектів. N00bs вимірює час завантаження ОС, і скажімо, наприклад, що Windows 2012 - це дуже добре, тому що він завантажується в 12 секунд на реальному HD, можливо, на SSD 1 сек.
Але такий показник не дуже корисний: продуктивність дорівнює часу завантаження ОС, але ОС завантажується раз на місяць настільки оптимізовано, що не має особливого сенсу.

Оскільки це мій щоденний бізнес, я можу зазначити чотири наступні частини, які складали "результативність"

1. Навантаження процесора
   Це повинно бути порівнянним, тобто завдання, що займає 1000 мс на голому металі, виконає за 1000 мс час роботи, і, ймовірно, 1050 мс тактового часу в простої ВМ-середовищі на тому ж апаратному забезпеченні (деякі деталі пізніше). Google MSDN for processtime and queryperformancecounter і yu можуть зробити те, що може показати, скільки VM з'їдає час вашого процесора.

2. Продуктивність SQL
   Продуктивність SQL дуже покладається на IO в сховище даних, де зберігаються дані SQL. Я бачив 300% різницю між ISCSI 1-го покоління, який ви можете знайти в домашньому НАС Буффало, потім ISCSI з DCE та реальним середовищем старої школи FC на всіх рівнях. ФК все ще виграє в наші дні, тому що затримка в FC є найнижчим архівом, який призводить до "копії" протоколу FC для вдосконалення центру обробки даних TCP / IP. Тут IOps та затримка є життєво важливим, але також пропускна здатність IO від серверного процесу до засобів масової інформації - залежить, якщо додаток прагне до No-SQL або Datawarehousing або знаходиться в середині такого, як ERP-системи ... Sage KHK для малих підприємств, SAP для величезних.

3. Доступ до файлової системи
   Деякі програми, наприклад, потокове відео покладається на гарантовану мінімальну пропускну здатність, інші покладаються на максимум пропускної здатності вводу-виводу, як-от просто відкриття великих файлів у шестигранному редакторі, завантажуючи відеопроект у свій улюблений фільм для створення фільму. Не типова ситуація на vm .... IOps також може бути важливою для розробників. Розробники часто використовують VM, оскільки середовище, що розвивається, дуже чутлива, і тому спокуса зробити це в VM велика. Складання великого проекту часто означає читання тонн невеликих файлів, робити компілятор і створювати EXE та супутні компоненти.

4. Затримка мережі до клієнта
   Тут зручність використання WYSIWIG-прог, таких як Word 2010, Openoffice Writer, LaTEX, GSView та інші, дуже покладається на швидкість - як швидко дію миші отримує від клієнта до сервера. Особливо це стосується програм CAD, але це важливо .... але також не проблема LAN, це віддалений доступ через WAN, де це важливо.

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

Але вони не мають на увазі, що це може працювати на ксеонах 1,5 ГГц на лезах, не створених для чистої роботи процесора, вони побудовані для середнього, скажімо, "оптимізованого для $ за цикл процесора" або "цикла процесора на ватт" .

А коли ми говоримо про компроміси та економії - це здебільшого призводить до надмірних комісій. Перезарядження призводить до нестачі ресурсів, де з процесором можна працювати досить добре, але відсутність пам’яті призводить до підкачки, відсутність IO в основних маршрутизаторах призводить до збільшення часу відповідей на все, а транзакційна перевантаження на будь-якому сховищі може зупинити кожну корисну програму від занадто швидкого реагування Тут необхідний моніторинг, але багато виробників програмного забезпечення не в змозі надати таку інформацію .... з іншого боку, хост з ресурсами 3 фізичних серверів, швидше за все, може обробляти 8 віртуальних машин того ж макета, як і фізичні ...

Компроміси процесора на холостих системах часто призводять до того, що системи працюють на 50% повільніше, ніж фізичні системи, з іншого боку, ніхто не в змозі встановити "реальний світ" ос та "реальний світ" додаток, який ІТ-хлопці клієнта хочуть перейти у VM ящик. І потрібні дні (можливо, тижні, але напевно 42 зустрічі), щоб зрозуміти, що технологія VM може запропонувати гнучкість, торгуючи чистою швидкістю процесора. Це просто вбудовані в процесори цих лезових систем, в яких зараз розміщуються більші VM середовища. Також пам'ять не буде порівнянною, також застосовуються деякі компроміси. DDR3 1600 CL10 матиме більшу пропускну здатність пам’яті, ніж LLR DDR2 800 ECC - і всім відомо, що процесори Intel отримують з цього прибуток інакше, ніж процесор AMD. Але їх рідко використовують у виробничих середовищах, більше у білих полях або в центрах даних, розміщених у країнах третього світу, які пропонують послугу центрів обробки даних на 10% від ціни, яку центр обробки даних на вашій батьківщині може стягувати ю. Завдяки Citrx центр обробки даних може бути скрізь, якщо затримка між кінцевим користувачем та центром обробки даних становить менше 150 мс.

А домашні користувачі перспективні….

Нарешті, але не менш важливо, що деякі люди хочуть викинути Win7 чи XP та торгувати ним для Linux, і тоді виникає ігрове питання, оскільки насправді для Linux та Windows доступно лише кілька ігор. Ігри дуже покладаються на 3D-прискорення. Робоча станція VMWare 6.5 та підключений безкоштовний програвач можуть працювати з DirectX 9, тобто Doom3 у VM може працювати на головній графічній карті в повноекранному режимі. Ігри - це в основному 32-бітні програми, тому вони не з’їдають більше 3 ГБ і в основному не більше 3 процесорів (видно на Crysis). Нові VM-плеєри та WS можуть підтримувати версії DirectX і, можливо, також OpenGL ... Я грав у UT та UT2004 на VMware 6.5, хост мав мобільний ATI Radeon 2600 та процесор T5440. Він був стабільним при 1280x800 та відтворювався навіть у мережевих іграх ....

Так. Але це не питання. Різниця зазвичай незначна (від 1% до 5%).

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

Я робив кілька тестових порівнянь того ж програмного забезпечення, що працює на тому ж тесті (веб-додаток на основі .NET з великими обсягами веб-трафіку та значним доступом до SQL Server). Ось що я бачив:

• Фізична машина краще в інстанціюванні класів (що перекладається на розподіл пам'яті на системному рівні) - це має сенс для мене, тому що фізичні машини роблять це через апаратне забезпечення управління пам'яттю, а ВМ - це за допомогою програмного забезпечення (з частковою апаратною допомогою) (На ВМ , додаток провів значну кількість часу у своїх конструкторах (де виділено пам'ять (і більше нічого не робиться), на фізичній машині конструктори навіть не були включені до перших 1000)
• Коли ви знаходитесь в середині методу, вони є приблизно еквівалентними - це, мабуть, так побудовано більшість орієнтирів, які показують два "однакові"
• Коли ви звертаєтесь до мережевого контролера, фізичний трохи вибиває VM - знову ж таки, фізичний не дуже сидить між процесом .NET і апаратним забезпеченням. VM додає додає інші "речі", через які потрібно пройти кожну транзакцію.
• Дійсно, те саме, що застосовано до доступу до дисків (SQL Server був на іншій машині) - різниця дуже мала, але коли ви додаєте їх усі, це помітно. Це могло бути викликано повільнішим доступом до мережі або повільнішим доступом до диска.

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

Ви намагаєтеся порівняти операційну систему, програмне забезпечення та дані, встановлені на певному фізичному обладнанні, з тією ж операційною системою, програмним забезпеченням та даними, встановленими самою собою всередині гіпервізора на тому самому оригінальному апаратному забезпеченні. Це порівняння просто не вірно, тому що майже ніхто цього не робить (принаймні спочатку). Звичайно, це, мабуть, буде повільніше. На щастя, він повністю пропускає найпоширеніший момент, чому ви взагалі віртуалізуєте сервери.

Кращим прикладом тут є перегляд двох (або більше!) Старих серверів у вашому центрі обробки даних. Шукайте сервери, які працюють досить добре, але вони вже старі і починають цикл оновлення. Ці сервери вже добре працюють на старій апараті, і тому завдяки закону Мура все, що ви отримаєте, буде набагато перевищеним.

Так, що ти робиш? Це просто. Замість того, щоб купувати два нових сервери, ви купуєте лише один, а потім переміщаєте обидва своїх старих серверів на той самий новий фізичний пристрій. Готуючись придбати новий сервер, ви плануєте так, щоб у вас була достатня потужність не тільки справляти навантаження з обох старих серверів, але і будь-яке навантаження від гіпервізора (а може бути і трохи додатково, щоб ви могли все-таки підвищити продуктивність і може дозволити зростання).

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

Тепер давайте розтягнемо це трохи далі. Оскільки це старі сервери, можливо, ви шукали кілька простих серверів коробки для піци в розмірі 1500 доларів, щоб замінити їх. Швидше за все, навіть одна з цих скриньок для піци все-таки може легко впоратися з вантажем з обох гіпотетичних старих машин ... але скажімо, ви вирішили витратити 7500 доларів або більше на реальне обладнання. Тепер у вас є пристрій, який може легко обробляти цілий десяток існуючих серверів (залежно від того, як ви обробляєте сховище та мережу), з початковою вартістю лише 5. Ви також маєте переваги лише від керування одним фізичним сервером, роз'єднання ваше програмне забезпечення від вашого обладнання (тобто: для оновлення обладнання зараз менше шансів на те, що вам потрібна нова ліцензія на Windows або виклик простоїв), ви економите енергію, і ваш гіпервізор може дати кращу інформацію про продуктивність, ніж ви ' я мав у минулому. Отримайте дві з них і залежно від того, наскільки ви великі, можливо, весь ваш центр обробки даних зводиться до всього лише двох машин, або, можливо, ви хочете використовувати другий сервер як гарячий режим очікування, щоб розповісти кращу історію доступності.

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

Я щойно оновився до SSD (OCZ Vertex 2) і на ньому запускаю своє середовище розробки XP VM, я розробник програмного забезпечення. Одне, що я помітив, це те, що коли я запускаю програму (одна достатня велика, щоб зайняти час для завантаження), одне ядро ​​віртуального процесора застрягає. Це трапляється і при завантаженні IE. Оскільки процесор чіпляється, я вважаю, що вузьким місцем є CPU, а не SSD. Але це здається дивним, у мене таке відчуття, що якщо те ж саме було зроблено на фізичній машині, воно завантажуватиметься швидше, і я відчуваю, що є додаткова обробка накладних витрат, що робить VMWare, що споживає ЦП на доступ до диску.

Один із прикладів: я використовую Delphi, і на фізичній машині, що має звичайний жорсткий диск, для холодного завантаження може знадобитися 20 секунд. У VM, який працює з SSD, він завантажується за 19 секунд від холодного пуску. Немає великої різниці, я думаю, що якби SSD був на фізичній машині, він завантажувався б швидше. Однак, я не перевіряв використання процесора на фізичній машині, його можливий процесор також був вузьким місцем.

Але відчуття VM полягає в тому, що доступ до диска оподатковує VM.

Очевидно, що віртуальна машина повільніше, ніж фізична. Але коли ви в цьому сценарії, ви повинні оцінити, що оптимально для задоволення ваших потреб. Якщо вам потрібна лише одна система, і вона потрібна для швидкої роботи, то встановіть її безпосередньо на обладнання. З іншого боку, якщо вам потрібна гнучкість, масштабованість (та всі інші переваги віртуалізації: P), розгорніть VM. Це буде повільніше, але IMHO в деяких випадках виправданий, а продуктивність не є значно повільною.

Схоже, Microsoft провів тестування на еталонах за допомогою сервера BizTalk та SQL Server у різних конфігураціях. Дивіться посилання нижче:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx

В ідеалі продуктивність віртуального ПК:

CPU: 96-97% хоста

Мережа: 70-90% хоста

Диск: 40-70% хоста

Вибачте, що не погоджуюся з TomTom.

Я деякий час використовую VMware Workstation в основному для Windows XP, Windows Vista та тепер рідних систем Windows Seven для роботи з різними смаками Windows, а також Ubuntu.

Так, віртуалізоване середовище повільніше, ніж у рідній системі, і це може бути в діапазоні від 5 до 100%.

Основна проблема - не стільки завантаження процесора, скільки фізична пам'ять.

Скажімо, у вас Windows Seven 64 Ultimate працює на 4 Гбіт системі, яка в режимі очікування потребує майже 1,5 Гбіт і використовує ~ 10% процесора. Запуск додаткового шару VMware коштуватиме вам ~ 300 Кб, а завантаження процесора підніметься до ~ 20%. Тоді запуск віртуальної системи у VMware вимагатиме мінімальної кількості пам'яті, яку ви визначили для цієї віртуальної машини, що становить мінімум 1 Гбіт для будь-якої гідної системи. Тоді ви побачите завантаження процесора ~ 60%, якщо віртуальна машина є Ubuntu і ~ 80% для будь-якого аромату останніх ОС Windows.

Тепер ви запускаєте різні програми в межах цієї віртуальної машини.

Якщо обсягу пам’яті, яку ви встановили для цієї віртуальної машини, недостатньо, віртуалізована система почне мінятись, а потім різко уповільнить її загальну продуктивність та чуйність.

Якщо сума обсягу пам’яті, яку ви встановили для цієї віртуальної машини плюс об’єм пам’яті, необхідної для вашої рідної системи, перевищує об’єм пам’яті вашої рідної системи, то ваша родна система збирається мінятись, сповільнюючи. як рідної, так і віртуалізованої системи.

Отже, спочатку це залежить від балансу пам'яті, необхідної як для рідної, так і для віртуалізованої машини.

Зараз це майже те саме з завантаженням процесора. Якщо віртуалізованому додатку потрібне велике завантаження процесора, а нативній програмі також потрібне величезне завантаження процесора, вашій рідній системі доведеться керувати пріоритетом і збалансувати заряд CPU між різними додатками, віртуалізована система - це не що інше, як додаток Явище - це класична проблема завантаження процесора, яку можна обдурити пріоритетами програми.

Отже, моя перша порада, якщо вам потрібно використовувати віртуалізацію, - це помістити купу пам’яті у вашу машину, незалежно від ОС, якою ви користуєтесь вдома або у віртуальній машині.

Всього мої 2 копійки.

З найкращими побажаннями.

На мій досвід, віртуальні машини завжди набагато повільніші, ніж фізичні, ВІД КОРОБКИ.

Ви це помітите лише під час запуску програм, які потрапляють на диск і багато оподатковують процесор. Я запустив багато баз даних та веб-серверів на віртуальних машинах, і як кінцевий користувач, і зворотній зв'язок від інших кінцевих користувачів (тобто: доступ до програми через віддалений веб-браузер) є досить великим відставанням при використанні віртуальних машин.

Звичайно, правильно налаштована віртуальна машина може досягати 80% (я не знаю реальної кількості) або будь-якої швидкості фізичної машини, але вам доведеться по-справжньому заглибитися в те, що робить додаток і як працює віртуальна машина працює. Тож я думаю, що це рівняння вартості того, наскільки цінним є ваш час на налаштування віршів VM, просто купівля та розміщення нового сервера.

Для мене віртуальні машини НЕ ПРО ДІЯЛЬНІСТЬ, а про те, що простіше керувати та розміщувати декілька низькопродуктивних VM.