web-dev-qa-db-ja.com

Linux-実際のハードウェアRAIDコントローラーのチューニング（SCSIおよびCCISS）

私が管理しているほとんどのLinuxシステムは、機能ハードウェアRAIDコントローラー（主に HP Smart Array ）です。それらはすべてRHELまたはCentOSを実行しています。

SASディスク（Smartアレイ、Perc、LSIなど）およびバッテリーバックアップまたはフラッシュ付きのハードウェアRAIDコントローラーを組み込んだセットアップのパフォーマンスを最適化するのに役立つ、実際の調整パラメータを探していますバックアップされたキャッシュRAID 1 + 0と複数のスピンドル（4+ディスク）を想定しています。

私はかなりの時間を費やして、低遅延で金融取引アプリケーション用のLinuxネットワーク設定を調整しています。しかし、それらのオプションの多くは十分に文書化されています（送信/受信バッファーの変更、TCPウィンドウ設定の変更など）。ストレージ側でエンジニアは何をしていますか？

歴史的に、私は I/Oスケジューリングエレベーター に変更を加えました。最近、deadlineおよびnoopスケジューラーを使用して、アプリケーション内のパフォーマンスを改善しました。 RHELのバージョンが進むにつれ、SCSIおよびCCISSブロックデバイスの組み込みのデフォルトも変更されていることにも気付きました。これは、推奨されるストレージサブシステムの設定に長期にわたって影響を及ぼしました。ただし、明確な推奨事項を確認してからしばらく経っています。そして、私はOSのデフォルトが最適ではないことを知っています。たとえば、サーバークラスのハードウェアでの展開では、デフォルトの128 KBの先読みバッファは非常に小さいようです。

次の記事では、read-aheadキャッシュを変更することによるパフォーマンスへの影響について説明します。 nr_requests ブロックキューの値。

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with-linux-why-tuning-really-matters
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

たとえば、これらはHP SmartアレイRAIDコントローラーの推奨される変更です。

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

ストレージのパフォーマンスを向上させるために、他に何を確実に調整できますか？
具体的には、実稼働シナリオでsysctlおよびsysfsオプションを探しています。

storagehphardware-raidperformance-tuninghp-smart-array
29
ewwhite

レイテンシとスループットを下げるために調整する必要があった場合、nr_requestsをデフォルトから（最低32に）調整しました。バッチを小さくするという考えは、レイテンシを下げることと同じです。

また、read_ahead_kbの場合、シーケンシャルな読み取り/書き込みの場合、この値を大きくするとスループットが向上することがわかりましたが、このオプションは実際にはワークロードとIOパターンに依存します。たとえば、最近調整したデータベースシステムでは、この値を単一のdbページサイズと一致するように変更しました。これにより、読み取りレイテンシが短縮されました。この値を超えて増減すると、私の場合、パフォーマンスが低下することがわかりました。

ブロックデバイスキューの他のオプションまたは設定については、次のとおりです。

max_sectors_kb =この値は、ハードウェアが1回の転送で許可する値と一致するように設定しました（sysfsのmax_hw_sectors_kb（RO）ファイルの値を確認して、許可される値を確認してください）

nomerges =これにより、ioリクエストをマージするためのルックアップロジックを無効化または調整できます。 （これをオフにすると、CPUサイクルを節約できますが、システムでこれを変更しても何のメリットもないので、デフォルトのままにしました）

rq_affinity =私はまだこれを試していませんが、これはカーネルのドキュメントからの背後にある説明です

このオプションが「1」の場合、ブロックレイヤーは最初にリクエストを送信したCPU「グループ」にリクエストの完了を移行します。一部のワークロードでは、これにより、キャッシュ効果によりCPUサイクルが大幅に削減されます。
完了処理の分散を最大化する必要があるストレージ構成の場合、このオプションを「2」に設定すると、要求のCPUで完了が強制的に実行されます（「グループ」集約ロジックをバイパスします）。

scheduler =あなたは締め切りを試して何もしなかったと言いました。私はnoopと締切の両方をテストしましたが、データベースサーバーに対して最近行ったテストでは締切の勝ちを見つけました。

NOOPは良好に機能しましたが、データベースサーバーでは、デッドラインスケジューラを調整することで、より良いパフォーマンスを達成できました。

/ sys/block/{sd、cciss、dm-} */queue/iosched /にある期限スケジューラのオプション：

fifo_batch = nr_requestsのようなものですが、スケジューラに固有です。経験則では、これを調整して待ち時間を短くするか、スループットを最大にします。読み取りおよび書き込みリクエストのバッチサイズを制御します。

write_expire =書き込みバッチの有効期限をデフォルトで5000msに設定します。もう一度この値を減らすと書き込みレイテンシが減少し、値を増やすとスループットが増加します。

read_expire =読み取りバッチの有効期限をデフォルトで500msに設定します。ここでも同じ規則が適用されます。

front_merges =これをオフにする傾向があり、デフォルトでオンになっています。 IOリクエストをフロントエンドしようとするCPUサイクルを無駄にするスケジューラの必要性を私は見ません。

writes_starved =期限は読み取りに向けられているため、ここでのデフォルトは、書き込みバッチが処理される前に2つの読み取りバッチを処理することです。デフォルトの2が自分のワークロードに適していることがわかりました。

38
rtorti19

ご参考までに read_ahead_kbおよびblockdev --setraは単なる 異なる単位を使用して同じ設定を設定するさまざまな方法 （KB対セクター）：

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

だから

blockdev --setra 65536 /dev/cciss/c0d0

あなたの例では効果はありません。

4
ntherning

何よりも、すべてはワークロードに依存します。

read_ahead_kbは、ビデオをストリーミングするときなど、事前にファイルから大量のデータを読み取ることが本当に役立つ場合に役立ちます。時にはそれはあなたをひどく傷つけることができます。はい、デフォルトの128 KBは小さいように聞こえるかもしれませんが、十分な同時実行性があると、大きく聞こえ始めます！一方、ビデオをフォーマットから別のフォーマットに変換するだけのビデオエンコーディングサーバーなどのサーバーでは、チューニングすることをお勧めします。

nr_requestsを調整しすぎると、RAIDコントローラーが簡単に溢れ、パフォーマンスが低下します。

現実の世界では、latencyを監視する必要があります。 SANに接続している場合は、iostat、sarなどの使用したいものを調べて、I/O要求のサービス時間が滞っているかどうかを確認します。もちろん、これはローカルディスクにも役立ちます。待ち時間が非常に大きい場合は、max_requestsおよびその他の設定をダウングレードしてI/Oエレベーターの設定を調整することを検討してください。

4
Janne Pikkarainen