KVM / Qemu, Ubuntu: Чому більше центральних процесорів для гостей швидко покращують диск / вхід?

У нас є кластер Heartbeat / DRBD / пейсмейкер / KVM / Qemu / libvirt, що складається з двох вузлів. Кожен вузол працює з Ubuntu 12.04 64 біт із наступними пакетами / версіями:

• Ядро 3.2.0-32-generic # 51-Ubuntu SMP
• ДРБД 8.3.11
• qemu-kvm 1.0 + noroms-0ubuntu14.3
• libvirt 0,9.13
• кардіостимулятор 1.1.7
• серцебиття 3.0.5

Віртуальні гості мають Ubuntu 10.04 64 біт і Ubuntu 12.04 64 біт. Ми використовуємо функцію libvirt для передачі можливостей хост-процесорів віртуальним гостям для досягнення найкращих показників процесора.

Тепер ось загальна настройка цього кластеру:

• ВМ «моніторинг» має 4 ВКП
• VM "моніторинг" використовує ide як дисковий інтерфейс (зараз ми переходимо на VirtIO з очевидних причин)

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

Вузол A працює VM "bla" Вузол B працює "VM" моніторинг "

Коли ми rsync файл з VM "bla" до VM "моніторинг", ми досягаємо лише 12 Мб / с. Коли ми виконуємо простий dd, якщо = / dev / null = = / tmp / blubb всередині "моніторингу" VM, ми досягаємо 30 Мб / с.

Потім ми додали ще 4 vCPU до «моніторингу» VM та перезапустили його. Тепер "моніторинг" ВМ має 8 вКПУ. Ми повторно провели тести з такими результатами: Коли ми rsync файл з VM "bla" до VM "моніторинг", ми тепер досягаємо 36 Мб / с. Коли ми виконуємо простий dd, якщо = / dev / null of = / tmp / blubb всередині «моніторингу» VM, ми досягаємо 61 Мб / с.

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

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

Я дам дуже грубу ідею / пояснення.

У ситуації з ОП, окрім вимірювань у ВМ, слід також звернути увагу на хоста.

У цьому випадку ми можемо вважати, що наступне є правильним

1. В усьому тесті пропускна здатність вузла вводу / виводу (диска) не перевищує максимальну. Зі "monitoring"збільшенням VM ( ) введення / виведення збільшується із збільшенням виділених йому процесорів. Якщо введення / виведення хоста вже було максимальним, посилення продуктивності вводу / виводу не повинно бути.
2. "bla"не є обмежуючим фактором, оскільки "monitoring"продуктивність вводу / виводу покращується без змін"bla"
3. Центральний процесор - це основна фабрика для підвищення продуктивності (у випадку з ОП), оскільки введення / виведення не є горловиною для пляшок, а OP не згадує про зміни розміру пам'яті. Але чому? Або як?

Додатковий фактор

1. Пишіть потрібно більше часу, ніж для читання. Це те саме для VM та для хоста. Сказати це надзвичайно просто: VM чекає, коли хост закінчить читати і писати.

Що станеться, коли більше процесора призначено "monitoring"?

Коли "monitoring"виділяється більше процесорів, він отримує більше процесорної потужності, але також отримує більше часу на обробку вводу / виводу.

Це не має нічого спільного, rsyncоскільки це програма з однією ниткою.

Це шар вводу / виводу, що використовує збільшену потужність процесора, а точніше - збільшений час обробки.

Якщо "monitoring"під час тестування використовується програма моніторингу процесора (наприклад, вгорі) , вона показуватиме не одне, але все використання процесора зростає, а також% wa. % wa - час очікування, витрачений на введення-виведення.

Це збільшення продуктивності відбудеться лише тоді, коли введення / виведення вашого хоста не має макс. з.

Я не можу знайти планування процесора на сайті KVM, але в цьому блозі згадується, що KVM використовує CFS та cgroups, наступна цитата

У межах KVM кожен vcpu відображається у процесі Linux, який, у свою чергу, використовує апаратну допомогу для створення необхідного «диму та дзеркал» для віртуалізації. Таким чином, vcpu - це ще один процес CFS, а також важливий для груп, який, як менеджер ресурсів, дозволяє Linux управляти розподілом ресурсів - як правило, пропорційно для встановлення розподілу обмежень. групи також застосовуються до пам'яті, мережі та вводу / виводу. Групи процесів можуть бути частиною групи планування, щоб застосувати вимоги до розподілу ресурсів до ієрархічних груп процесів.

Коротше кажучи, більше CPU = більше процесорного часу = більше інтервал часу вводу / виводу за певний проміжок часу.