KVM / Qemu, Ubuntu: Почему все больше гостевых процессоров быстро улучшают дисковый ввод-вывод?

9

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

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

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

Теперь вот общая настройка этого кластера:

  • ВМ "мониторинг" имеет 4 виртуальных ЦП
  • «Мониторинг» виртуальной машины использует ide в качестве интерфейса диска (в настоящее время мы переходим на VirtIO по понятным причинам)

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

Узел A работает под управлением виртуальной машины "bla". Узел B работает под управлением виртуальной машины.

Когда мы rsync файл с ВМ "Bla" для "Мониторинг" ВМ, мы достигаем только 12 МБ / с. Когда мы выполняем простой dd if = / dev / null of = / tmp / blubb внутри «мониторинга» виртуальной машины, мы достигаем около 30 МБ / с.

Затем мы добавили еще 4 виртуальных ЦП к «мониторингу» ВМ и перезапустили его. «Мониторинг» виртуальной машины теперь имеет 8 виртуальных ЦП. Мы повторно запустили тесты со следующими результатами: Когда мы rsync файл с виртуальной машины «bla» для мониторинга «VM», мы теперь достигаем 36 МБ / с. Когда мы выполняем простой dd if = / dev / null of = / tmp / blubb внутри «мониторинга» виртуальной машины, мы достигаем около 61 МБ / с.

Для меня этот эффект довольно удивителен. Как получается, что добавление дополнительных виртуальных процессоров для этого виртуального гостя автоматически означает увеличение производительности диска внутри виртуальной машины?

У меня нет объяснения этому, и я был бы очень признателен за ваш вклад. Я хочу понять, что вызывает это увеличение производительности, так как я могу воспроизвести это поведение на 100%.

performance kvm-virtualization central-processing-unit libvirt qemu Valentin
источник
2
Используйте специальный инструмент для тестирования производительности, такой как iozone или bonnie ++, чтобы помочь устранить другие переменные.
ewwhite
Было бы интересно, как выглядят фактические загрузки процессора ... это что-то, связанное с процессором, введенное в скрытом месте (rsync плюс, вероятно, ssh, безусловно, в некоторой степени, так что сетевые драйверы введены таким образом, также dd может делать неожиданные вещи, связанные с процессором) ...), или это на самом деле вещи неоптимально ждут друг друга из-за меньшего количества доступных потоков выполнения?
rackandboneman
3
запустить, kvm_traceчтобы увидеть, как количество IO_Exitsизменений при изменении номера процессора. Я думаю, это потому, что вы используете IDE, которая запланирована с гостевыми процессорами. С virtio производительность должна быть согласованной, а когда data-plane находится в qemu, он получит радикальный прирост. Другое предположение может заключаться в том, что вы используете дистрибутив, который известен как глючный стек виртуализации.
Дясный
@ Ewwhite: Да, проведение профессиональных тестов было бы хорошим выбором. Однако сначала я хочу понять, почему происходит такое поведение ввода-вывода. @ rachandboneman: Когда я смотрел последний раз, 4 процессора имели очень высокое значение ожидания (около 70-80%). @dyasny: Спасибо, я попробую это. Как я могу проверить, что плоскость данных активирована / используется в настоящее время?
Валентин
На данный момент data-plane экспериментальный, и я уверен, что первым дистрибутивом будет Fedora. pl.digipedia.org/usenet/thread/11769/28329
дясный

Ответы:

9

Я дам очень грубую идею / объяснение.

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

В этом случае мы можем предположить, что верно следующее

  1. Во всех тестах пропускная способность хоста ввода / вывода (диска) не максимальная. Поскольку VM ( "monitoring") I / O увеличивается с большим количеством процессоров, выделенных для него. Если хост-ввод / вывод уже был максимально исчерпан, не должно быть увеличения производительности ввода-вывода.
  2. "bla"не является ограничивающим фактором, поскольку производительность "monitoring"ввода-вывода улучшилась без изменений в"bla"
  3. Процессор является основной фабрикой для увеличения производительности (в случае OP), поскольку ввод / вывод не является узким местом, и OP не упоминает никаких изменений размера памяти. Но почему? Или как?

Дополнительный фактор

  1. Запись занимает больше времени, чем чтение. Это то же самое для виртуальной машины и хоста. Проще говоря: VM ждет, пока хост завершит чтение и запись.

Что произойдет, когда больше процессоров назначено "monitoring"?

Когда "monitoring"выделяется больше процессоров, он получает больше вычислительной мощности, но также получает больше времени обработки для ввода-вывода.

Это не имеет ничего общего с тем, rsyncчто это однопотоковая программа.

Это уровень ввода-вывода, использующий повышенную мощность ЦП или, точнее, увеличенное время обработки.

Если "monitoring"во время теста используется программа мониторинга процессора (например, top) , она покажет не одну, а всю загрузку процессора, а также% wa. % wa - время ожидания на ввод / вывод.

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

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

В KVM каждый vcpu сопоставлен с процессом Linux, который, в свою очередь, использует аппаратную помощь для создания необходимых «дымов и зеркал» для виртуализации. Таким образом, vcpu - это просто еще один процесс для CFS, а также, что важно, для cgroups, который, как менеджер ресурсов, позволяет Linux управлять распределением ресурсов - обычно пропорционально, чтобы устанавливать распределения ограничений. cgroups также применяются к памяти, сети и I / O. Группы процессов могут быть включены в группу планирования для применения требований выделения ресурсов к иерархическим группам процессов.

В двух словах: больше процессора = больше времени процессора = больше временного интервала ввода / вывода в данный период времени.

Джон Сиу
источник
Спасибо, что написали этот ответ. «Больше виртуальных ЦП означает больше времени на обработку ввода / вывода» - вот объяснение, которое я искал. Стоит щедрость!
Валентин