GlusterFS 用の Linux カーネルのセットアップ

記事の翻訳はコース開始前夜に準備されました 管理者 Linux。 プロ".

カーネルチューニングに関する Gluster の推奨事項と、その必要があるかどうかについて、定期的に疑問が生じます。

そのようなニーズが生じることはほとんどありません。 ほとんどのワークロードで、カーネルは非常に良好にパフォーマンスします。 欠点もありますが。 歴史的に、Linux カーネルは、パフォーマンスを向上させる主な方法としてのキャッシュなど、機会があれば大量のメモリを消費することをいとわなかった。

ほとんどの場合、これは問題なく機能しますが、負荷が高い場合は問題が発生する可能性があります。

当社には、CAD、EDA など、高負荷になると速度が低下し始める、メモリを大量に使用するシステムに関する豊富な経験があります。 また、Gluster で問題が発生することもありました。 メモリ使用量とディスク遅延を何日間も注意深く観察した結果、過負荷、巨大な iowait、カーネル エラー (カーネル oops)、フリーズなどが発生していることがわかりました。

この記事は、さまざまな状況で実行された多くのチューニング実験の結果です。 これらのパラメーターのおかげで、全体的な応答性が向上しただけでなく、クラスターも大幅に安定しました。

メモリのチューニングに関しては、まず仮想メモリ サブシステム (VM、仮想メモリ) に注目します。これには、混乱を招く可能性のある多数のオプションがあります。

vm.swappiness

パラメーター vm.swappiness カーネルが RAM と比較してスワップ (スワップ、ページング) をどれだけ使用するかを決定します。 ソースコードでは「マップされたメモリを盗む傾向」とも定義されています。 スワップ性が高いということは、カーネルがマップされたページをよりスワップする傾向があることを意味します。 スワッピー値が低いとその逆を意味し、カーネルがメモリからページングする量が少なくなります。 つまり、値が大きいほど vm.swappiness、システムがスワップを使用する量が多くなります。

膨大なデータ ブロックが RAM にロードおよびアンロードされるため、スワッピングを多量に使用することは望ましくありません。 多くの人が swapiness 値を大きくするべきだと主張しますが、私の経験では、これを「0」に設定するとパフォーマンスが向上します。

ここで詳細を読むことができます - lwn.net/記事/100978

ただし、繰り返しになりますが、これらの設定は慎重に適用し、特定のアプリケーションをテストした後にのみ適用する必要があります。 負荷の高いストリーミング アプリケーションの場合、このパラメータは「0」に設定する必要があります。 「0」に変更するとシステムの応答性が向上します。

vm.vfs_cache_pressure

この設定は、ディレクトリおよび inode オブジェクト (dentry および inode) をキャッシュするためにカーネルによって消費されるメモリを制御します。

デフォルト値の 100 では、カーネルは、ページキャッシュおよびスワプキャッシュに対して「公平な」基準で dentry キャッシュと i ノード キャッシュを解放しようとします。 vfs_cache_pressure を下げると、カーネルは dentry キャッシュと i ノード キャッシュを保持します。 値が「0」の場合、カーネルはメモリ不足のため dentry キャッシュと i ノード キャッシュをフラッシュしません。これにより、メモリ不足エラーが発生しやすくなります。 vfs_cache_pressure を 100 より大きくすると、カーネルは dentry と i ノードのフラッシュを優先します。

GlusterFS を使用する場合、大量のデータと多数の小さなファイルを持つ多くのユーザーは、inode/dentry キャッシュによりサーバー上の大量の RAM を容易に使用する可能性があり、カーネルがシステム上のデータ構造を処理する必要があるため、パフォーマンスの低下につながる可能性があります。 40GBのメモリを搭載。 この値を 100 より大きく設定すると、多くのユーザーがより公平なキャッシュを実現し、カーネルの応答性が向上するようになりました。

vm.dirty_background_ratio と vm.dirty_ratio

最初のパラメータ (vm.dirty_background_ratio) ダーティ ページが含まれるメモリの割合を決定します。この割合に達すると、バックグラウンドでダーティ ページをディスクにフラッシュし始める必要があります。 このパーセンテージに達するまで、ページはディスクにフラッシュされません。 また、リセットが開始されると、実行中のプロセスを中断することなくバックグラウンドで実行されます。

XNUMX 番目のパラメータ (vm.dirty_ratio) は、強制フラッシュが開始される前にダーティ ページによって占有できるメモリの割合を定義します。 このしきい値に達すると、すべてのプロセスが同期 (ブロック) になり、要求した I/O が実際に完了し、データがディスク上に置かれるまで続行できなくなります。 I/O が多い場合、データ キャッシュが存在せず、I/O を実行するすべてのプロセスが I/O を待機してブロックされるため、問題が発生します。 これにより、多数のプロセスがハングし、高負荷が発生し、システムが不安定になり、パフォーマンスが低下します。

これらの設定を減らすと、データがより頻繁にディスクにフラッシュされ、RAM に保存されなくなります。 これは、45 ～ 90 GB のページ キャッシュをディスクにフラッシュすることが通常であるため、フロントエンド アプリケーションに大きな待ち時間が発生し、全体的な応答性と対話性が低下する、メモリを大量に使用するシステムに役立ちます。

"1" > /proc/sys/vm/pagecache

ページ キャッシュは、ファイルおよび実行可能プログラムのデータを保存するキャッシュです。つまり、これらはファイルまたはブロック デバイスの実際の内容を含むページです。 このキャッシュは、ディスクの読み取り回数を減らすために使用されます。 値「1」は、RAM の 1% がキャッシュに使用され、RAM からの読み取りよりもディスクからの読み取りの方が多くなることを意味します。 この設定を変更する必要はありませんが、ページ キャッシュの制御に不安がある場合は、この設定を使用できます。

"デッドライン" > /sys/block/sdc/queue/scheduler

I/O スケジューラは、読み取りキューと書き込みキューを処理する Linux カーネル コンポーネントです。 理論的には、スマート RAID コントローラーには「noop」を使用する方が良いです。Linux はディスクの物理的なジオメトリについて何も知らないため、ディスクのジオメトリをよく知っているコントローラーにリクエストをできるだけ早く処理させるほうが効率的です。可能。 ただし、「期限」を使用するとパフォーマンスが向上するようです。 スケジューラの詳細については、Linux カーネル ソース コードのドキュメントを参照してください。 linux/Documentation/block/*osched.txt。 また、混合操作 (多数の書き込み) 中の読み取りスループットの増加も確認しました。

"256" > /sys/block/sdc/queue/nr_requests

スケジューラに渡される前のバッファ内の I/O リクエストの数。 一部のコントローラーの内部キュー サイズ (queue_ Depth) は I/O スケジューラーの nr_requests よりも大きいため、I/O スケジューラーがリクエストを適切に優先順位付けしてマージできる可能性はほとんどありません。 デッドラインおよび CFQ スケジューラの場合、nr_requests がコントローラの内部キューの 2 倍である場合に適しています。 リクエストをマージして並べ替えると、高負荷時のスケジューラの応答性が向上します。

echo "16" > /proc/sys/vm/page-cluster

page-cluster パラメーターは、一度にスワップに書き込まれるページの数を制御します。 上記の例では、RAID ストライプ サイズ 16 KB に従って、値は「64」に設定されます。 swappiness = 0 では意味がありませんが、swappiness を 10 または 20 に設定すると、RAID ストライプ サイズが 64K の場合にこの値を使用すると役に立ちます。

blockdev --setra 4096 /dev/<開発者名> (-sdb、hdc、または dev_mapper)

多くの RAID コントローラーのデフォルトのブロック デバイス設定では、パフォーマンスが低下することがよくあります。 上記のオプションを追加すると、4096 * 512 バイトのセクターの先読みが設定されます。 少なくとも、ストリーミング操作の場合、カーネルが I/O を準備するために使用する期間中に、オンチップ ディスク キャッシュを先読みで埋めることによって速度が向上します。 キャッシュには、次回の読み取り時に要求されるデータを含めることができます。 プリフェッチが多すぎると、潜在的に有用なディスク時間を使い果たしたり、キャッシュの外にデータをロードしたりすると、大きなファイルのランダム I/O が無効になる可能性があります。

以下に、ファイル システム レベルでの推奨事項をさらにいくつか示します。 しかし、それらはまだテストされていません。 ファイルシステムがストライプのサイズとアレイ内のディスクの数を認識していることを確認してください。 たとえば、これは 5 つのディスク (パリティに 64 つのディスクが使用されるため、実際には XNUMX つ) からなる XNUMXK ストライプの RaidXNUMX アレイであるとします。 これらの推奨事項は理論的な仮定に基づいており、RAID 専門家によるさまざまなブログ/記事からまとめられています。

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

大きなファイルの場合は、上記のストライプ サイズを増やすことを検討してください。

警告！ 上で説明したことはすべて、一部の種類のアプリケーションでは非常に主観的です。 この記事は、関連アプリケーションの事前のユーザー テストがなければ、改善を保証するものではありません。 システム全体の応答性を向上させる必要がある場合、または現在の問題を解決する場合にのみ使用してください。

追加の資料

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• llkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

続きを読む

• Red Hat Enterprise Linux 8 での nftables の使用

出所： habr.com