☰

QEMU + KVM + LVM — производительность блочного устройства и образа файла

tag-icon • tag-icon linux filesystems lvm qemu
QEMU + KVM + LVM — производительность блочного устройства и образа файла

Я создаю новую настройку для своих виртуальных машин и тестирую, какой метод хранения самый быстрый. Моя тестовая среда состоит из жесткого диска с LVM на LUKS. Я создал один LV для диска виртуальной машины и повторно использовал его для обоих тестов, чтобы сохранить то же место на жестком диске для поддержания постоянной производительности (скорость чтения/записи жесткого диска зависит от физического положения).

  • Хост: Arch Linux, ядро ​​4.12.8
  • Гость: Ubuntu Desktop 17.04

Производительность проверена с помощью команды:

    dd if=/dev/zero of=test bs=16M count=100 conv=sync

Первый тест: использование LV напрямую в качестве диска виртуальной машины

Команда:

qemu-system-x86_64 \
  -drive format=raw,file=/dev/mapper/vg_vm-lv_vm_test,if=virtio,aio=native,cache.direct=on \
  -net nic,model=virtio \
  -net user \
  -vga virtio \
  -display gtk,gl=on \
  -smp 3 \
  -cpu host \
  -machine type=pc,accel=kvm \
  -m 3G

Результаты (каждое значение представляет отдельный запуск):

  • Создание нового файла: 98,4 МБ/с ; 112 МБ/с
  • Запись в существующий файл: 62,5 МБ/с; 68,7 МБ/с; 64,8 МБ/с

Второй тест: создание ext4 на LV и размещение на нем файла образа raw

Команда:

qemu-system-x86_64 \
  -drive format=raw,file=./ubuntu_17,if=virtio,aio=native,cache.direct=on \
  -net nic,model=virtio \
  -net user \
  -vga virtio \
  -display gtk,gl=on \
  -smp 3 \
  -cpu host \
  -machine type=pc,accel=kvm \
  -m 3G

Результаты (каждое значение представляет отдельный запуск):

  • Создание нового файла: 254 МБ/с ; 242 МБ/с
  • Запись в существующий файл: 187 МБ/с ; 189 МБ/с ; 190 МБ/с

Третий тест: использование LV непосредственно в качестве диска виртуальной машины, различные настройки

Команда:

qemu-system-x86_64 \
  -drive format=raw,file=/dev/mapper/vg_vm-lv_vm_test,if=virtio,cache=none \
  -net nic,model=virtio \
  -net user \
  -vga virtio \
  -display gtk,gl=on \
  -smp 3 \
  -cpu host \
  -machine type=pc,accel=kvm \
  -m 3G

Результаты (каждое значение представляет отдельный запуск):

  • Создание нового файла: 129 МБ/с ; 125 МБ/с
  • Запись в существующий файл: 103 МБ/с ; 97 МБ/с ; 81,9 МБ/с

Вопрос

Очевидно, что между этими двумя решениями есть разница, однако я ожидал, что устройство raw block будет по крайней мере таким же быстрым, как файл образа, поскольку не должно быть никаких накладных расходов на файловую систему хоста. Я предполагаю, что между файлом image происходит некоторое кэширование или параметры для raw block device не оптимальны. Почему raw LV медленнее в этом случае? Что я могу сделать, чтобы улучшить его производительность? Или если он просто должен быть медленнее, то почему?

EDIT: Я добавил третий тестовый случай, используя настройки из:http://www.linux-kvm.org/page/Настройка_KVM. Оказывается, немного быстрее, но все равно медленнее, чем образ файла. Я также заметил, что с каждым запуском для существующего файла он становится медленнее - однако фрагментация не должна происходить при перезаписи файла, поэтому я не уверен, почему это происходит.

решение1

Проблема может быть в несоответствии размера блока.

В идеале вы хотите, чтобы ваша файловая система соответствовала базовому размеру блока носителя. Хотя вы не поделились тем, что выбрали для размеров блоков, я думаю, у вас есть 4 килобайта для попытки Ext4 и 512 байт для LV. Если естественный размер блока вашего базового носителя составляет 4 килобайта, то я думаю, это объясняет как вашу проблему со скоростью, так и вашу уменьшающуюся скорость. Поскольку вы, возможно, записываете только 512 в блок 4k, вы тратите впустую 75% блока, и последующие записи будут использовать больше блоков, что приведет к большим накладным расходам и потерям.

Повторите тест с точно подобранным размером блока файловой системы, соответствующим размеру базового медиа-блока. В этом случае попробуйте использовать LV с размером блока 4k.

LVM добавляет немного больше накладных расходов, чем Ext4. Ответ на Stack Overflow Думаю, это объясняет, почему он немного медленнее. :)

Связанный контент