Чрезвычайно низкая производительность хранилища qemu с образами qcow2
Я запускаю несколько изображений, используя libvirt на небольшом кластере Openstack. Производительность хранилища на этих машинах чрезвычайно низка: мой инструмент мониторинга показывает 100% -ное использование (обычно при записи, но иногда при чтении) с пропускной способностью от ~ 50 КБ / с до максимальной примерно 1 МБ / с.
Это скриншот nmon инструмент, показывающий производительность ЦП с течением времени и текущую пропускную способность хранилища. То, что они показывают, типично:
Я воспроизвел ту же проблему производительности на двух других машинах, используя packer инструмент для создания образов Debian и Ubuntu с помощью qemu. Вот моя командная строка qemu:
/ usr / bin / qemu-system-x86_64 -netdev user, id = user.0, hostfwd = tcp :: 3213-: 22 -device virtio-net, netdev = user.0 -cdrom / home / $ user / packer_cache / 23e6874116128e16e11cfad1c369c54be97c20023e59b9b9d39d312233e09cd6.iso -m 512M -display sdl -machine type = pc, accl = kvm -vnc 0.0.0.0:47 -name packer-openstack -drive file = packer-openstack -drive file = packer-openstack -drive file = packer-openstack -drive file = output-output-openstack -drive file = packer-openstack -drive file = output-output-openstack -drive file = output-openq -drive file = output нет - загружаться один раз = d
Как видите, я использую virtio водитель, и cache=none.
Я даже пропатчил упаковщик, чтобы использовать -o preallocation=metadata в аргументах qemu-img create. Казалось, что это немного улучшило ситуацию, но производительность осталась на несколько порядков ниже, чем в хост-системе.
Этот конкретный снимок экрана был сделан на этапе «Установка базовой системы» при установке Ubuntu, но он более или менее соответствует любому использованию хранилища.
Это было сделано на моей рабочей станции - Macbrook Pro с твердотельным накопителем; машина Openstack, имеющая ту же проблему, работает с кластером RAID10, который я тестировал на скорости записи около 1200 МБ / с в хост-системе.
Очевидно, я не ожидаю, что производительность хранилища в qemu будет соответствовать производительности хост-системы - но замечательно, насколько это медленно. Хост-виртуальным машинам в кластере Openstack требуется несколько секунд для выполнения таких простых операций, как CREATE DATABASE заявление в postgres.
На данный момент единственное, что у меня осталось, - это снимок экрана:
Вот nmon показывает, что /dev/sda имеет полную загрузку, но /dev/sda7 - раздел, который на самом деле содержит образ qcow2 - используется только 1%. Последняя статистика соответствует тому, что я действительно ожидал от производительности диска.
Стоит отметить, что насыщенность здесь не просто артефакт моего инструмента мониторинга: все при этом операции на хост-машине выполняются очень медленно.
Как я могу отследить, что здесь происходит на самом деле?
Стоит ли мне смотреть на такие вещи, как использование elevator=noop на хозяине и гостях настроить планировщик?
-
редактировать: Вот результат uname -a на моей рабочей станции:
Linux $hostname 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 GNU/Linux
А вот на машине Openstack:
Linux $hostname 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Серверная часть файла Qcow2 может быть значительно медленной при настройке cache = none. Более того, "-o prellocation = metadata" предварительно выделяет только метаданные, а фактические данные файла будут фрагментированы. Другими словами, файл qcow2 остается разреженным с коротким интервалом выделения (для метаданных). Раньше появлялась опция «-o preallocation = full», но в последней версии qemu-img я ее не обнаружил.
Вы можете попробовать:
1) использовать cache=writeback (гораздо безопаснее, чем "небезопасный" вариант)
2) предварительно выделите весь файл qcow2, выполнив "fallocate <filename> <filesize>"в файле qcow2?
Вы можете найти другую информацию Вот и Вот.
Очевидно, проделайте указанную выше операцию только на тестировании ВМ! Если после тестирования все в порядке, вы можете распространить изменения на другие виртуальные машины.
cache=none вероятно, не лучшая идея, когда вы используете файлы qcow2. Файл qcow2 создает впечатление, что каждый доступ к диску фрагментирован. Это означает, что вы каждый раз получаете производительность диска с произвольным доступом, а некоторые флэш-накопители ужасно медленны (написано правильно) при произвольной записи.
Попробуйте с cache=unsafe (временно), чтобы подтвердить, что это проблема, либо выберите режим кеширования, в котором вас устраивает компромисс (я бы выбрал cache=writethrough на большинстве машин и cache=writeback если на ext3 / 4 в режиме регистрации данных) или измените формат виртуального диска.
Если ни один из режимов кеширования не подходит, вам нужен более линейный формат диска, например, логические тома lvm (я предпочитаю) или необработанные файлы изображений. IME с lvm производительность qemu очень близка к производительности хоста.