👩🏿‍🍳 🧐 💆🏾 GlusterFSのLinuxカーネル構成 👨🏼‍🏫 🏭 🔫

記事の翻訳は、コース「AdministratorLinux」の開始前夜に作成されました。プロフェッショナル」。

定期的に、カーネルのチューニングに関するGlusterの推奨事項と、これが必要かどうかについて、あちこちで質問があります。

そのような必要性はまれです。カーネルは、ほとんどのワークロードで非常にうまく機能します。欠点はありますが。歴史的に、Linuxカーネルは、パフォーマンスを向上させるための主な方法としてのキャッシュを含め、機会が与えられれば、すぐに多くのメモリを消費します。

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

CADやEDAなど、高負荷で速度が低下し始めた、大量のメモリを消費するシステムについては、多くの経験があります。そして時々私達はGlusterの問題に遭遇しました。使用されているメモリとディスクの遅延を1日以上注意深く観察した後、過負荷、巨大なiowait、カーネルエラー（カーネルエラー）、フリーズなどが発生しました。

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

メモリの調整に関して、最初に確認するのは仮想メモリ（VM）サブシステムです。これには、混乱を招く可能性のある多数のオプションがあります。

vm.swappiness

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

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

あなたはここでより多くの詳細を読むことができます-lwn.net/Articles/100978

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

vm.vfs_cache_pressure

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

デフォルトの100では、カーネルはdentryキャッシュとinodeキャッシュをpagecacheとswapcacheに公平に解放しようとします。 vfs_cache_pressureを減らすと、カーネルはdentryキャッシュとinodeキャッシュを保持します。値が0の場合、メモリの負荷が不十分なため、カーネルがdentryキャッシュとinodeキャッシュをクリアすることはありません。これにより、メモリ不足エラーが発生しやすくなります。 vfs_cache_pressureを100より大きくすると、カーネルはdentryとinodeのアンロードを優先します。

GlusterFSを使用すると、大量のデータと多くの小さなファイルを持つ多くのユーザーが、inode / dentryキャッシングにより、サーバー上で大量のRAMを簡単に使用できます。これは、カーネルが40 GBのメモリを備えたシステムでデータ構造を処理する必要があるため、パフォーマンスの低下につながる可能性があります。 ..。このパラメータを100以上に設定すると、多くのユーザーがより公平なキャッシュとカーネルの応答性の向上を実現するのに役立ちます。

vm.dirty_background_ratioおよびvm.dirty_ratio

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

2番目のパラメーター（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 /ブロック/ sdc /キュー/スケジューラー

I / Oスケジューラは、読み取りキューと書き込みキューを処理するLinuxカーネルコンポーネントです。理論的には、スマートRAIDコントローラーには「noop」を使用することをお勧めします。Linuxはディスクの物理的なジオメトリについて何も知らないため、ディスクのジオメトリに精通したコントローラーにできるだけ早く要求を処理させる方が効率的です。しかし、締め切りはパフォーマンスを改善するようです。スケジューラの詳細については、Linuxカーネルのソースコードのドキュメントを参照してください linux/Documentation/block/*osched.txt。また、混合操作（多くの書き込み）中に読み取りスループットが向上することもわかりました。

"256"> / sys /ブロック/ sdc /キュー/ nr_requests

スケジューラーに送信される前のバッファー内のI / O要求の数。一部のコントローラーの内部キューサイズ（queue_depth）はI / Oスケジューラーのnr_requestsよりも大きいため、I / Oスケジューラーはリクエストに適切な優先順位を付けてマージする可能性がほとんどありません。期限およびCFQスケジューラーの場合、nr_requestsがコントローラーの内部キューの2倍であるとよいでしょう。クエリを組み合わせて並べ替えると、プランナーは高負荷の下で応答性が向上します。

echo "16"> / proc / sys / vm / page-クラスター

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

blockdev --setra 4096 / dev / `<`devname `>`（-sdb、hdc、またはdev_mapper）

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

以下は、ファイルシステムレベルでのガイドラインです。しかし、それらはまだテストされていません。ファイルシステムがストライプサイズとアレイ内のディスク数を認識していることを確認してください。たとえば、64Kのストライプサイズが6ディスクのraid5アレイです（1つのディスクがパリティに使用されるため、実際には5つです）。これらの推奨事項は理論上の仮定に基づいており、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))

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

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

追加資料：

続きを読む

Red Hat Enterprise Linux8でのnftablesの使用

GlusterFSのLinuxカーネル構成