web-dev-qa-db-ja.com

LinuxソフトウェアRAID-10でのパフォーマンスの低下

私は8チャネルLSISAS3008コントローラーチップを搭載したマシンを持っていますが、個々のドライブテストでは、任意のディスクまたはすべてのディスクに174 MB /秒から193MB /秒の範囲で持続的な書き込み速度で書き込むことができることが示されています。

これは、コマンドdd if=/dev/zero of=/dev/mapper/mpath?p1 bs=1G count=100 oflag=direct run in parallelから12個のディスクすべてへの出力です。

107374182400 bytes (107 GB) copied, 556.306 s, 193 MB/s
107374182400 bytes (107 GB) copied, 566.816 s, 189 MB/s
107374182400 bytes (107 GB) copied, 568.681 s, 189 MB/s
107374182400 bytes (107 GB) copied, 578.327 s, 186 MB/s
107374182400 bytes (107 GB) copied, 586.444 s, 183 MB/s
107374182400 bytes (107 GB) copied, 590.193 s, 182 MB/s
107374182400 bytes (107 GB) copied, 592.721 s, 181 MB/s
107374182400 bytes (107 GB) copied, 598.646 s, 179 MB/s
107374182400 bytes (107 GB) copied, 602.277 s, 178 MB/s
107374182400 bytes (107 GB) copied, 604.951 s, 177 MB/s
107374182400 bytes (107 GB) copied, 605.44 s, 177 MB/s

ただし、これらのディスクをソフトウェアRAID 10デバイスとしてまとめると、約500MB /秒の書き込み速度が得られます。これらのディスクに同時にアクセスしてもペナルティがないため、約2倍になると予想していました。

ソフトウェアRAID自体が80％に近づいており、1つのコアが常に100％の待機時間で、0％がアイドル状態であると想定しているmd10_raid10プロセスに気づきました。ただし、どのコアが変更されます。

さらに、oflag = directを使用してキャッシュをバイパスするのではなく、バッファキャッシュを使用してマウントされたEXT4ファイルシステムに書き込むと、パフォーマンスがさらに低下します。ディスクは（muninモニタリングによると）25％のビジー状態を報告しますが、ディスクは明らかにホットになっていないのですが、md10デバイス自体がホットになっているのではないかと心配しています。

これについて次にどこに行くべきかについての提案はありますか？私はハードウェアRAID10構成を比較しようとしていますが、10ディスクユニットしか構築できないようです-とはいえ、900MB /秒の書き込みを維持したいと思っています。詳細がわかり次第、この質問を更新します。

編集1：

そのデバイスにマウントされたext4パーティションへの書き込みをタイトループでputddコマンドを使用し、バッファーキャッシュ（oflag = direct）を使用しない場合、ピーク時に950MB /秒以上を取得できますマウントフラグにいくつかの変更を加えて、855MB /秒を維持しました。

同じタイミングでiflag = directを使用して読み取ると、480 MB /秒の書き込みと750MB /秒の読み取りが可能になります。

Oflag = directを使用せずに、つまりバッファキャッシュを使用して書き込むと、230 MB /秒の書き込みと1.2MB /秒の読み取りが発生しますが、マシンの動作が非常に遅いようです。

それで、問題は、なぜバッファキャッシュを使用することがパフォーマンスにそれほど深刻な影響を与えるのでしょうか？ドライブレベルで「noop」を使用し、適切なマルチパスdmデバイスに「deadline」または「cfq」を設定するか、すべてに期限を設定するか、dmに期限を設定せず、バッキングドライブに期限を設定するなど、さまざまなディスクキューイング戦略を試しました。バッキングドライブには何もないはずであり、マルチパスデバイスは私が望むものでなければならないようですが、少なくともバッファキャッシュの場合、これはパフォーマンスにまったく影響しません。

linuxsoftware-raidsaslsi
3
Michael Graff

編集：

dd oflag=directの観察結果は、電源管理の問題が原因である可能性があります。 PowerTOP を使用して、書き込み負荷の下でCPUのC状態がC1より上で頻繁に切り替わるかどうかを確認します。そうである場合は、PMを調整して、CPUがスリープ状態にならないようにし、ベンチマークを再実行してください。その方法については、ディストリビューションのドキュメントを参照してください。ほとんどの場合、これはintel_idle.max_cstate=0カーネルブートラインパラメータ、ただしYMMV。

O_DIRECT書き込みとバッファリングされた書き込みのパフォーマンスの大きな違いは、次の理由による可能性があります。

  • o_DIRECTを使用する場合、CPUはC3 +スリープに送信されません。
  • cPUはC3 +に送信されますが、O_DIRECTを使用する場合の処理​​が大幅に簡素化されるため、それほど重要ではありません。ゼロ化されたメモリ領域をポイントし、DMA書き込み要求を発行するのに必要なサイクルは、バッファリングされた処理であり、レイテンシの影響を受けにくくなります

廃止された回答：

これは、mdの単一スレッドによって引き起こされるボトルネックに非常によく似ています。

推論

  • コントローラーのデータシート は6,000のスループットを約束しています
  • 並列のdd実行は170MBを示しています/ s+ドライブごと。したがって、パスは接続するPCIe帯域幅によって制限されません。
  • md10_raid10の使用率はほぼ100％と高くなっています

マルチスレッドRAID5チェックサム計算のパッチ 2013年にmdraid にコミットされましたが、同様のRAID1/RAID10拡張機能については何も見つからないため、単に存在しない可能性があります。

試すべきこと

  • ddを使用した複数の書き込みスレッド、何かが変更されるかどうかを確認するため
  • 別のRAID10実装- LVM RAID 1 が思い浮かびますが、 ZFSを見てください1 これはまさにこのユースケース（多くのディスク、ハードウェアRAIDコントローラーなし）を念頭に置いて設計されています
  • おそらくより新しいカーネルバージョン

FWIWでは、メカニックストレージメディアを使用した帯域幅で書き込みパフォーマンスがピークアウトすることはめったにありません（特に非CoWファイルシステムの場合）。ほとんどの場合、シーク時間によって制限されるため、最小要件を満たしている限り、ピーク帯域幅はそれほど重要ではありません。

1 ZFSをdoする場合は、ZFSデータセットへのすべてゼロのブロックの書き込みが任意の速度で行われる可能性があるため、テスト方法を改良する必要があります。ゼロはディスクに書き込まれませんが、データセットに対して圧縮が有効になっている場合はすべてゼロブロックにリンクされます。

3
the-wabbit