Чрезвычайно низкая производительность хранилища qemu с изображениями qcow2
Я запускаю некоторые изображения, используя libvirt на небольшом кластере Openstack. Производительность хранилища на этих машинах крайне низкая: мой инструмент мониторинга показывает 100% -ное использование (обычно при записи, а иногда и при чтении) с пропускной способностью от ~50 КБ / с до макс. Около 1 МБ / с.
Это скриншот nmon инструмент, показывающий производительность процессора с течением времени и текущую пропускную способность хранилища. То, что они показывают, типично:
Я повторил ту же проблему производительности на двух других машинах, используя packer инструмент для создания образов Debian и Ubuntu с использованием qemu. Вот моя командная строка qemu:
/ usr / bin / qemu-system-x86_64 -netdev пользователь,id=user.0,hostfwd=tcp::3213-:22 -девайс virtio-net,netdev=user.0 -cdrom /home/$user/packer_cache/23e6874116128e16e11cfad1c369c54be97c20023e59b9b9d39d312233e09cd6.iso -m 512M -display sdl -машинный тип =pc,accel=kvm -vnc 0.0.0.0:47 -name имя упаковщика-openstack-openstack-openstack =virg = файл-файла = файл-вывода = файл вирк = файл-файла = выход-файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл = выходной файл нет -загрузка один раз = d
Как видите, я использую virtio водитель и cache=none,
Я даже исправил упаковщик, чтобы использовать -o preallocation=metadata в аргументах qemu-img create, Похоже, это немного улучшило ситуацию, но производительность осталась на порядок ниже, чем в хост-системе.
Этот конкретный снимок экрана был сделан во время этапа установки Ubuntu "Установка базовой системы", но он соответствует более или менее любому использованию хранилища.
Это было сделано на моей рабочей станции Macbrook Pro с SSD; на машине 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
2 ответа
Бэкэнд файла 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 очень близка к производительности хоста.