Linux-実世界のハードウェアRAIDコントローラーのチューニング（scsiおよびcciss）

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

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

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

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

次の記事では、ブロックキューの先読みキャッシュと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オプションを具体的に探しています。

レイテンシー対スループットを低く調整する必要がある場合、nr_requestsをデフォルトから（最低32）に調整していることがわかりました。バッチが小さいという考え方は、待ち時間が短いことと同じです。

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

ブロックデバイスキューの他のオプションまたは設定に関して：

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

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

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

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

スケジューラー =期限とヌープを試みたと言いました。noopとdeadlineの両方をテストしましたが、データベースサーバーに対して最近行ったテストではdeadline winが出ていることがわかりました。

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がワークロードに適していることがわかりました。

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

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

nr_requests、オーバーチューンすると、RAIDコントローラーが簡単にあふれ、パフォーマンスが低下します。

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

参考までに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

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