KVMディスクのパフォーマンスが非常に低い（qcow2ディスクファイル+ virtio）

KVMゲストのセットアップ中に深刻なディスクパフォ​​ーマンスの問題が発生しています。単純な使用ddテストを、QCOW2画像が（ミラーリングRAIDアレイ）上に存在することをホスト上のパーティションは、上で書き込み120メガバイト/ sの私のゲストからの範囲の書き込みを取得しながら、0.5 3メガバイト/秒にし。

• ゲストはいくつかの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スケジューラが有効になっており、ゲストにはnoopがあります。

kvmのパフォーマンスを調整するガイドがたくさんあるようで、最終的にはそこに到達しますが、この時点でこれよりもはるかに優れたパフォーマンスを得る必要があるように思われるので、すでに何かが非常に間違っているようです。

アップデート1

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

更新2

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

そうですね、qcow2ファイルは、非常に高速なパフォーマンスのために設計されていません。生のパーティション（または、できればLV）からより良い運が得られます。

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+が必要です！繰り返しますが、現代のディストリビューションのほとんどはこれらを持っています。

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

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

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

私のqemu-kvmバージョンは1.0+noroms-0ubuntu14.8、3.2.0-41-genericUbuntu 12.04.2 LTSのカーネルです。

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

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

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

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

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

キャッシュモードに関する注意：ディスクキャッシュフラッシュ/バリアのサポートがないか、無効になっているゲストを使用しない限り、ライトバックキャッシュが優先モードです。実際には、Win2000 +ゲストとLinux EXT4、XFS、またはEXT3 + barrierマウントオプションは問題ありません。一方、キャッシュ=安全ではないが必要があります決してキャッシュフラッシュがホストシステムに伝播されないよう、生産機械の使用しないこと。予期しないホストのシャットダウンは、ゲストのファイルシステムを文字通り破壊する可能性があります。

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

長い話：バッキングストレージがvirtio_blk（vda、vdbなど）ストレージコントローラーに接続されている場合-iSCSIターゲットに接続しているiSCSIクライアントからのパフォーマンスは私の環境で〜20 IOPS、スループット（IOサイズに依存）〜2 3 MiB /秒。仮想マシン内の仮想ディスクコントローラーを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>