web-dev-qa-db-ja.com

重いTPSおよび書き込みワークロードに対するqemu / KVM最適化

RAID 0 SSDで30個のVMを実行しています。

VMワークロードは重いDocker環境です（正確にはdocker-composeで、約40のコンテナーを実行しています）。

CPU負荷平均とRAM使用量はどちらもサーバーの快適なパラメーターの範囲内です。ただし、ディスク使用率は非常に大きく、iostatはTPSとMB_wrtnの数値が作業の場所であることを示しています完了：

_Device:  tps       MB_read/s   MB_wrtn/s   MB_read   MB_wrtn
md5      2825.57   3.28        28.15       1673116   14379843
_

現在、VMディスクを次のように定義しています：

_<driver name='qemu' type='raw' cache='none' io='threads'/>
<source file='os.img' aio='native'/>
_

私のVMホストはCentOS Linux 7 (Core)でカーネル_3.10.0-1062.18.1.el7.x86_64_を使用しており、その結果、deadlineスケジューラーを使用しています。ゲストはより新しいカーネルであり、デフォルトで_mq-deadline_スケジューラーに設定されています。

最適化に関する実際の情報、およびどのキャッシング/ IO戦略を使用するかについての多くの矛盾するアドバイスを見つけるのに苦労しています。

これはベンチマークするのが本当に難しいです-ワークロードの最も重い部分がキックするのに2〜3時間かかる可能性があり、ディスクの使用率が低下するのは約30分だけです-これは作業の重要な部分です。ディスク使用率が低い場合と比較して、大幅な速度低下を引き起こしています。

したがって、私の質問は次のとおりです。

  • cache、io、aioのどの組み合わせが、高いTPS /書き込みワークロードで最高のパフォーマンスを提供しますか？
  • 「予備」のCPUリソースがある場合、iothreadsを使用する必要がありますか？

さらに、特に私のホストのカーネルバージョンに関連します。

  • カーネルバージョン_3.17_ +にアップグレードして_blk-mq_（ブロックマルチキュー）にアクセスする必要がありますか？
  • その場合、QEMU/KVMセットアップ/定義でこれをどのように有効にしますか？
  • _blk-mq_で使用するのに最適なゲストスケジューラは何ですか-単なるnoneですか？

できるだけ早くこの質問に対する賞金を授与します。

===編集===

  • 通常の完全なワークロードの後、上記のiostat出力を更新しました
  • RAID0アレイで4x 2TB Samsung PM883 SSDを使用しています（ソフトウェアRAID）
  • 以下にいくつかのベンチマーク統計を追加しました：

fio /ホストのRAID0アレイからのioping

_Jobs: 1 (f=1): [m(1)][100.0%][r=421MiB/s,w=139MiB/s][r=108k,w=35.7k IOPS][eta 00m:00s]
---
9 requests completed in 1.65 ms, 36 KiB read, 5.45 k iops, 21.3 MiB/s
_

fio /ホストのRAID1 OSアレイからのioping

_Jobs: 1 (f=1): [m(1)][100.0%][r=263MiB/s,w=86.7MiB/s][r=67.3k,w=22.2k IOPS][eta 00m:00s]
---
9 requests completed in 1.50 ms, 36 KiB read, 6.00 k iops, 23.5 MiB/s
_

VMのvdaデバイスからのfio

_Jobs: 1 (f=1): [m(1)] [100.0% done] [246.2MB/82458KB/0KB /s] [62.1K/20.7K/0 iops] [eta 00m:00s]
_

私は各VMを最大2300読み取り/ 800書き込みiopsに調整しましたが、いくつかの奇妙な理由により、状況が大幅に悪化します。非常に多くのタイムアウトとジョブエラーが発生します。 。

ワークロードの途中でGrafanaは次のようになります。

grafana dashboard

linuxkvm-virtualizationqemu
2
dunc

おそらく問題の根本は、SATAインターフェイスを備えたSSDがあることです。 SATAにはコマンドキューが1つしかないため、SATAバス上の複数のコマンドを並行して実行することはできません。 SASはこれを少し改善しますが、最大64kの独立したキューを持つNVMeを使用すると、大幅に改善されました。

SATAでキューの深さを増やすと、単一の操作のレイテンシが増加します（スループットは増加します）。これはおそらく、VM IOPSを増やしたときに起こったことです。

blk-mqを備えたSATA SSDの大きな利益は期待できません。同じことがiothreadsにも当てはまります。 SATAインターフェイスでの競合を回避することはできません。

これはおそらくあなたが探しているものではありませんが、NVMeベースのSSDへのハードウェアアップグレードが最善の選択肢だと思います。スケジューラーの調整では、ハードウェアの制限を回避できません。

2
Bernhard