LinuxでのJBODパフォーマンスへのSASマルチパスの改善

Linux搭載の一部のSunハードウェアでストレージ設定を最適化しようとしています。どんな考えでも大歓迎です。

次のハードウェアがあります。

Sun Blade X6270
2 * LSISAS1068E SASコントローラー
2 * Sun J4400 JBOD、1 TBディスク（JBODごとに24ディスク）
Fedora Core 12
FC13の2.6.33リリースカーネル（FC12の最新の2.6.31カーネルでも試したが、同じ結果が得られた）

SASハードウェアのデータシートは次のとおりです。

http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf

PCI Express 1.0a、8xレーンを使用しています。レーンごとに250 MB /秒の帯域幅があれば、SASコントローラーごとに2000 MB /秒を実行できるはずです。

各コントローラーは、ポートごとに3 Gb /秒を実行でき、2つの4ポートPHYを備えています。コントローラからの両方のPHYをJBODに接続します。したがって、JBODとコントローラーの間には、2つのPHY * 4つのSASポート* 3 Gb /秒= 24 Gb /秒の帯域幅があり、これはPCI Expressの帯域幅よりも大きくなります。

書き込みキャッシュを有効にして、大量の書き込みを行う場合、各ディスクは約80 MB /秒（ディスクの開始近く）を維持できます。24個のディスクがあれば、JBODごとに1920 MB /秒を実行できるはずです。

マルチパス{
  rr_min_io 100
  uid 0
  path_grouping_policy multibus
  フェールバックマニュアル
  path_selector "ラウンドロビン0"
  rr_weight優先度
  エイリアスsomealias
  no_path_retryキュー
  モード0644
  gid 0
  wwid somewwid
}

rr_min_ioに50、100、1000の値を試しましたが、それほど大きな違いはないようです。

さまざまなrr_min_ioに加えて、ddを開始する間に遅延を追加して、それらすべてが同じPHYを同時に上書きするのを防ぐことを試みましたが、これは違いをもたらさなかったため、I / Oは適切に広がっていると思います。

/ proc / interruptsによると、SASコントローラーは「IR-IO-APIC-fasteoi」割り込みスキームを使用しています。何らかの理由で、マシンのコア＃0だけがこれらの割り込みを処理しています。各SASコントローラーの割り込みを処理する別のコアを割り当てることで、パフォーマンスをわずかに改善できます。

エコー2> / proc / irq / 24 / smp_affinity
エコー4> / proc / irq / 26 / smp_affinity

ddを使用してディスクに書き込むと、「関数呼び出し割り込み」が生成され（これらが何であるかはわかりません）、コア＃4によって処理されるため、他のプロセスもこのコアから切り離します。

私は48個のDD（ディスクごとに1つ）を実行し、それらをコアに割り当てて、次のように割り込みを処理しません。

taskset -c somecore dd if = / dev / zero of = / dev / mapper / mpathx oflag = direct bs = 128M

oflag = directは、あらゆる種類のバッファキャッシュが関与するのを防ぎます。

どのコアも使い果たされているようには見えません。割り込みを処理するコアはほとんどアイドル状態で、他のすべてのコアは予想どおりI / Oを待機しています。

Cpu0：0.0％us、1.0％sy、0.0％ni、91.2％id、7.5％wa、0.0％hi、0.2％si、0.0％st
Cpu1：0.0％us、0.8％sy、0.0％ni、93.0％id、0.2％wa、0.0％hi、6.0％si、0.0％st
Cpu2：0.0％us、0.6％sy、0.0％ni、94.4％id、0.1％wa、0.0％hi、4.8％si、0.0％st
Cpu3：0.0％us、7.5％sy、0.0％ni、36.3％id、56.1％wa、0.0％hi、0.0％si、0.0％st
Cpu4：0.0％us、1.3％sy、0.0％ni、85.7％id、4.9％wa、0.0％hi、8.1％si、0.0％st
Cpu5：0.1％us、5.5％sy、0.0％ni、36.2％id、58.3％wa、0.0％hi、0.0％si、0.0％st
Cpu6：0.0％us、5.0％sy、0.0％ni、36.3％id、58.7％wa、0.0％hi、0.0％si、0.0％st
Cpu7：0.0％us、5.1％sy、0.0％ni、36.3％id、58.5％wa、0.0％hi、0.0％si、0.0％st
Cpu8：0.1％us、8.3％sy、0.0％ni、27.2％id、64.4％wa、0.0％hi、0.0％si、0.0％st
Cpu9：0.1％us、7.9％sy、0.0％ni、36.2％id、55.8％wa、0.0％hi、0.0％si、0.0％st
Cpu10：0.0％us、7.8％sy、0.0％ni、36.2％id、56.0％wa、0.0％hi、0.0％si、0.0％st
Cpu11：0.0％us、7.3％sy、0.0％ni、36.3％id、56.4％wa、0.0％hi、0.0％si、0.0％st
Cpu12：0.0％us、5.6％sy、0.0％ni、33.1％id、61.2％wa、0.0％hi、0.0％si、0.0％st
Cpu13：0.1％us、5.3％sy、0.0％ni、36.1％id、58.5％wa、0.0％hi、0.0％si、0.0％st
Cpu14：0.0％us、4.9％sy、0.0％ni、36.4％id、58.7％wa、0.0％hi、0.0％si、0.0％st
Cpu15：0.1％us、5.4％sy、0.0％ni、36.5％id、58.1％wa、0.0％hi、0.0％si、0.0％st

このすべてを前提として、「dstat 10」を実行して報告されるスループットは、2200〜2300 MB /秒の範囲です。

上記の計算を考えると、2 * 1920〜= 3600+ MB /秒の範囲の値が期待されます。

誰かが私の失われた帯域幅がどこに行ったのか考えていますか？

ありがとう！

LSI SASコントローラーのキャッシュはライトスルーに設定されていますか？（大規模な順次ワークロードの場合、ライトバックは遅くなります）。bs = 1Mのように、ddのbsを小さくしてテストすることもできます。

— ブライアン

素敵な、よく準備された質問:)

私自身はスピードとフィードマンで、正直に言うとお金を稼いでいると思います。私は半分よりもスループットが低くなることを期待していましたが、あなたが得たものはマイナーで期待された非効率の蓄積です。たとえば、PCIeバスが常に100％に到達するのは非常に困難です。全体のレートが90％と低いと想定した方がよいでしょう。ジッターを考えると、これはPHYが常に100％「供給」されないことを意味するので、キャッシュ、ディスク、非協調割り込み、IOスケジューリングなどと同じように、そこに少し失われます。それは、マイナーな非効率性の時間、マイナーな非効率性の時間、などのように、最終的には、それ自体で予想される非効率性の5〜10％を超えることになります。HP DLサーバーがW2K3を使用してMSA SASボックスと通信し、NLBになるこのようなことを私は見ました。複数のNICで編集-イライラするが理解できると思います。それはとにかく私の2cです。申し訳ありませんが、あまり肯定的ではありません。

— チョッパー3
ソース