web-dev-qa-db-ja.com

信じられないほど低いKVMディスクパフォ​​ーマンス（qcow2ディスクファイル+ virtio）

KVMゲストを設定しているときに深刻なディスクパフォ​​ーマンスの問題が発生しています。簡単なddテストを使用して、qcow2イメージが存在するホスト上のパーティション（ミラーリングされたRAIDアレイ）は120MB/s以上で書き込みますが、私のゲストは.5から3MB/sの範囲の書き込みを取得します。

  • ゲストはいくつかのCPUと4GのRAM=で構成されており、現在何も実行していないため、現時点では完全に最小限のインストールです。
  • パフォーマンスはtime dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000を使用してテストされています。
  • ゲストはvirtioを使用するように構成されていますが、これはパフォーマンスに影響を与えないようです。
  • ホストパーティションは4kbアラインメントです（とにかくホストのパフォーマンスは良好です）。
  • ディスクでライトバックキャッシュを使用すると、報告されたパフォーマンスが大幅に向上しますが、使用しない方がよいでしょう。それがなくても、パフォーマンスはこれよりはるかに優れているはずです。
  • ホストとゲストはどちらもUbuntu 12.04 LTSを実行しています。これにはqemu-kvm 1.0 + noroms-0ubuntu13とlibvirt 0.9.8-2ubuntu17.1が付属しています。
  • ホストの期限IOスケジューラーが有効になっていて、ゲストには何もできません。

Kvmのパフォーマンスを調整するガイドはたくさんあるようですが、最終的にはそこに行きますが、現時点ではこれよりもはるかに優れたパフォーマンスが得られるはずなので、何かがすでに非常に間違っているようです。

更新1

そして突然私が戻って今テストすると、それは26.6 MB/sです。これは、私がw/qcrow2で期待したものに似ています。問題が何だったのかについて誰かが何か考えを持っている場合に備えて（そして不思議なことに再び戻ってきた場合に備えて）、質問はそのままにしておきます。

更新2

私はqcow2のパフォーマンスについて心配するのをやめ、生のイメージを使用してRAID1の上でLVMに切り替わりました。まだvirtioを使用していますが、ディスクドライブでcache = 'none'およびio = 'native'を設定しています。書き込みパフォーマンスはappxになりました。 135MB/s上記と同じ基本テストを使用しているため、問題を簡単に完全に回避できる場合、問題が何であるかを理解することはあまり重要ではないようです。

performancekvm-virtualizationqcow2
29
El Yobo

ええ、そうです、qcow2ファイルは、驚くほど高速なパフォーマンスを実現するように設計されていません。 rawパーティション（またはできればLV）からより良い運が得られます。

15
womble

達成方法QCOW2で最高のパフォーマンス：

qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ

Qcow2開発者によると、最も重要なのはニースを後押しする事前割り当てです。ほぼLVMと同等になりました！これは通常、最新の（Fedora 25以降）Linuxディストリビューションで有効になっていることに注意してください。

また、これが本番インスタンスではないの場合、安全でないキャッシュを提供できます（これは危険であり、推奨されません。テストにのみ適しています）。

<driver name='qemu' cache='unsafe' />

一部のユーザーは、この構成が一部のテストでLVM /安全でない構成に勝ると報告しています。

これらすべてのパラメーターについて最新のQEMU 1.5 +が必要です！繰り返しますが、現代のディストリビューションのほとんどはこれらを持っています。

8
lzap

この設定でqcow2イメージの素晴らしい結果を達成しました：

<driver name='qemu' type='raw' cache='none' io='native'/>

ゲストキャッシュを無効にし、AIO（非同期IO）を有効にします。 ddコマンドを実行すると、ホストで177MB/s、ゲストで155MB/sが得られました。イメージは、ホストのテストが行​​われたのと同じLVMボリュームに配置されます。

俺の qemu-kvmバージョンは1.0+noroms-0ubuntu14.8およびカーネル3.2.0-41-genericストックUbuntu 12.04.2 LTSから。

6
gertas

私はまったく同じ問題を経験しました。 RHEL7仮想マシン内には、他のマシンが接続するLIO iSCSIターゲットソフトウェアがあります。 iSCSI LUNの基盤となるストレージ（バックストア）として、最初はLVMを使用しましたが、その後、ファイルベースのイメージに切り替えました。

簡単に言うと、バッキングストレージがvirtio_blk（vda、vdbなど）ストレージコントローラーに接続されている場合、iSCSIターゲットに接続するiSCSIクライアントからのパフォーマンスは私の環境にあり、スループットは20 IOPSでした（IO size）〜2-3 MiB/s。仮想マシン内の仮想ディスクコントローラーをSCSIに変更し、iSCSIクライアントから1000+ IOPSとスループット100+ MiB/sを得ることができます。

<disk type='file' device='disk'>
   <driver name='qemu' type='qcow2' cache='none' io='native'/>
   <source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
   <target dev='sda' bus='scsi'/>
   <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
3
Greg W

単一のコマンドでvmsを実行している場合、引数には次を使用できます

kvm -drive file =/path_to.qcow2、if = virtio、cache = off <...>

3MB /秒から70MB /秒になりました

2
Kourindou Hime

Qemu/KVMの古いバージョンでは、Qcow2バックエンドは事前に割り当てられていないと非常に遅くなりました。ライトバックキャッシュを有効にせずに使用するとさらに遅くなります。 詳細はこちらをご覧ください。

最近のQemuバージョンでは、事前割り当てを使用しない（またはメタデータのみの事前割り当て）場合でも、Qcow2ファイルははるかに高速です。 それでも、LVMボリュームは高速のままです。

キャッシュモードに関する注意：writebackキャッシュは、ディスクキャッシュのフラッシュ/バリアのサポートがない、または無効なゲストを使用しない限り、推奨されるモードです。実際には、Win2000 +ゲストとLinux EXT4、XFS、またはEXT3 +バリアマウントオプションは問題ありません。一方、キャッシュフラッシュはホストシステムに伝播されないため、本番マシンではcache = unsafeをnever使用しないでください。予期しないホストのシャットダウンは、文字通りゲストのファイルシステムを破壊する可能性があります。

2
shodanshok