QEMU + KVM + LVM - ブロックデバイスドライブとファイルイメージのパフォーマンス

QEMU + KVM + LVM - ブロックデバイスドライブとファイルイメージのパフォーマンス

仮想マシン用の新しいセットアップを作成し、どのストレージ方法が最も高速かをテストしています。テスト環境は、LUKS 上の LVM を備えた HDD ドライブで構成されています。仮想マシン ドライブ用に単一の LV を作成し、両方のテストでそれを再利用して、HDD ドライブ上の同じ場所を維持し、一貫したパフォーマンスを維持します (HDD の読み取り/書き込み速度は物理的な位置によって異なります)。

  • ホスト: Arch Linux、カーネル 4.12.8
  • ゲスト: Ubuntu デスクトップ 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

結果 (各値は 1 回の実行を表します):

  • 新しいファイルの作成: 98.4 MB/秒、112 MB/秒
  • 既存ファイルへの書き込み: 62.5 MB/秒、68.7 MB/秒、64.8 MB/秒

2番目のテスト: LVにext4を作成し、そこに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

結果 (各値は 1 回の実行を表します):

  • 新しいファイルの作成: 254 MB/秒、242 MB/秒
  • 既存ファイルへの書き込み: 187 MB/秒、189 MB/秒、190 MB/秒

3番目のテスト: 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

結果 (各値は 1 回の実行を表します):

  • 新しいファイルの作成: 129 MB/秒、125 MB/秒
  • 既存ファイルへの書き込み: 103 MB/秒、97 MB/秒、81.9 MB/秒

質問

明らかに、これら 2 つのソリューションには違いがありますが、ホストのファイルシステムのオーバーヘッドはないため、raw ブロック デバイスは少なくともイメージ ファイルと同じ速度になると予想していました。ファイル イメージの場合は途中でキャッシュが発生するか、raw ブロック デバイスのオプションが最適ではないと考えられます。この場合、raw LV が遅いのはなぜですか? パフォーマンスを向上させるにはどうすればよいですか? または、単に遅くなる必要がある場合は、その理由は何ですか?

編集: 次の設定を使用して 3 番目のテスト ケースを追加しました:http://www.linux-kvm.org/page/Tuning_KVM少し速くなりますが、ファイル イメージよりは遅いです。また、既存のファイルを実行するたびに遅くなっていることも確認しました。ただし、ファイルの上書きでは断片化は発生しないはずなので、なぜ発生するのかはわかりません。

答え1

ブロック サイズの不一致が問題である可能性があります。

理想的には、ファイル システムをメディアの基盤となるブロック サイズと一致させる必要があります。ブロック サイズとして選択したサイズを共有していませんが、Ext4 の試行に 4 キロバイト、LV に 512 バイトがあると思います。基盤となるメディアの自然なブロック サイズが 4 キロバイトである場合、速度の問題と速度の低下の両方がこれで説明できると思います。4k ブロックに 512 しか書き込んでいない可能性があるため、ブロックの 75% が無駄になり、その後の書き込みでさらに多くのブロックが使用され、オーバーヘッドと無駄が増えます。

基盤となるメディア ブロック サイズと適切に一致するファイル システム ブロック サイズでテストを再試行します。この場合は、4k ブロック サイズの LV を試してください。

LVM は Ext4 よりも少しオーバーヘッドを追加します。 スタックオーバーフローの回答 だから、なぜ少し遅くなるかがこれで説明できると思います。:)

関連情報