qcow2イメージでのqemuストレージのパフォーマンスが非常に遅い
小さなOpenstackクラスターでlibvirtを使用していくつかのイメージを実行しています。これらのマシンのストレージパフォーマンスは非常に低くなります。私の監視ツールは、100％の使用率（通常は書き込み時、場合によっては読み取り時）を示し、スループットは約50KB /秒、最大で約1MB /秒です。
これは、経時的なCPUパフォーマンスと現在のストレージスループットを示すnmonツールのスクリーンショットです。彼らが示すものは典型的です：
packerツールを使用してqemuを使用するDebianおよびUbuntuイメージをビルドすることにより、他の2つのマシンで同じパフォーマンスの問題を再現しました。ここに私のqemuコマンドラインがあります：
/ usr/bin/qemu-system-x86_64 -netdev user、id = user.0、hostfwd = tcp :: 3213-：22 -device virtio-net、netdev = user.0 -cdrom/home/$ user/packer_cache/23e6874116128e16e11cfad1c369c54be97c20023e59b9b9d39d312233e09cd6.iso -m 512M -display sdl -machine type = pc、accel = kvm -vnc 0.0.0.0:47 -name packer-openstack -drive file = output-openstack/packer-openstack.qcow2、if =なし-boot once = d
ご覧のとおり、私はvirtioドライバーとcache=noneを使用しています。
-o preallocation=metadataの引数にqemu-img createを使用するようにパッカーにパッチを適用しました。これにより、状況はわずかに改善されたように見えましたが、パフォーマンスはホストシステムよりも桁違いに低くなっています。
この特定のスクリーンショットは、Ubuntuインストールの「ベースシステムのインストール」の段階で撮影されましたが、ストレージの使用状況とほぼ一致しています。
SSDを搭載したMacbrook Proである私のワークステーションで撮影されました。同じ問題のあるOpenstackマシンは、ホストシステムで約1200MB/sの書き込みでベンチマークしたRAID10クラスターを実行しています。
明らかに、qemuでのストレージパフォーマンスがホストシステムのストレージパフォーマンスに匹敵するとは思っていませんが、これがどれほど遅いかは注目に値します。 Openstackクラスター上のホストVMは、postgresのCREATE DATABASEステートメントと同じくらい簡単な操作を実行するのに数秒かかります。
現時点で私が残した唯一の手掛かりは、このスクリーンショットです：
ここでnmonは、/dev/sdaが完全に使用されていることを示していますが、/dev/sda7-実際にqcow2イメージを保持しているパーティション-は1％しか使用していません。後者の統計は、ディスクパフォーマンスが実際にここにあると私が実際に期待するものと一致します。
ここでの飽和は、私の監視ツールの単なるアーティファクトではないことに注意する必要があります。これが発生している間、ホストマシンでのall操作は非常に低速です。
ここで実際に起こっていることをどのように追跡できますか？
ホストとゲストで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
Qcow2ファイルバックエンドは、cache = none設定を使用すると大幅に遅くなる可能性があります。さらに、「-o prellocation = metadata」はメタデータのみを事前に割り当て、実際のファイルデータは断片化されます。言い換えると、qcow2ファイルは、割り当ての短いストローク（メタデータ用）のみを持つスパースファイルのままです。過去には「-o preallocation = full」オプションが表示されていましたが、最近のqemu-imgバージョンでは見つかりませんでした。
次のことを試すことができます。
1）cache=writebackを使用します（「安全でない」オプションの方がはるかに安全です）
2）qcow2ファイルで "fallocate <filename> <filesize>"を発行して、qcow2ファイル全体を事前に割り当てますか？
明らかに、テストで上記の操作を実行しますVM only！テスト後にすべて問題なければ、変更を他のVMに伝播できます。
cache=noneは、qcow2ファイルを使用している場合はおそらくお勧めできません。 qcow2ファイルにより、ディスクへのすべてのアクセスが断片化されているように見えます。これは、ドライブのランダムアクセスパフォーマンスが毎回得られることを意味し、一部のフラッシュドライブはランダム書き込みで非常に低速です（スペルが意図したとおり）。
cache=unsafeで（一時的に）これが問題であることを確認してから、トレードオフに満足できるキャッシュモードを選択します（ほとんどのマシンではcache=writethroughを使用しますが、cache=writebackデータロギングモードのext3/4の場合）、または仮想ディスクのフォーマットを変更します。
どのキャッシュモードも受け入れられない場合は、よりリニアなディスクフォーマットが必要です（例：lvm論理ボリューム（推奨）またはrawイメージファイル）。 lvmを使用したIMEの場合、qemuのパフォーマンスはホストのパフォーマンスに非常に近いです。