🥇カーネル設定 Linux GlusterFS向け

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

カーネルチューニングに関する Gluster の推奨事項とその必要性について、時々疑問が生じます。

このようなニーズはめったに発生しません。ほとんどのワークロードでは、コアは非常に優れたパフォーマンスを発揮します。ただし、欠点もあります。歴史的に、コアは Linux 機会があれば、パフォーマンス向上の主な手段としてのキャッシュを含め、積極的に大量のメモリを消費する。

ほとんどの場合、これで問題なく動作しますが、負荷が大きい場合には問題が発生する可能性があります。

当社は、高負荷時に速度が低下し始める CAD、EDA などのメモリを大量に消費するシステムに関して豊富な経験を持っています。そして、Gluster で問題が発生することもありました。 1 日以上にわたってメモリ使用量とディスク待機時間を注意深く監視した結果、過負荷、膨大な iowait、カーネル oops、フリーズなどの問題が発生しました。

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

メモリを構成する場合、最初に確認する必要があるのは仮想メモリ (VM) サブシステムです。このサブシステムには多数のオプションがあり、混乱する可能性があります。

vm.swappiness

パラメーター vm.swappiness RAM と比較してカーネルがスワップを使用する量を決定します。ソースコードでは、「マップされたメモリを盗む傾向」とも定義されています。 swappiness 値が高いということは、カーネルがマップされたページをスワップアウトする傾向が強くなることを意味します。 swappiness 値が低いということはその逆であり、カーネルがメモリからスワップアウトするページ数が少なくなります。つまり、価値が高ければ高いほど vm.swappinessシステムがスワップを使用する頻度が高くなります。

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

詳細はこちらをご覧ください - lwn.net/記事/100978

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

vm.vfs_cache_pressure

このパラメータは、ディレクトリオブジェクトと inode をキャッシュするためにカーネルが消費するメモリを制御します。

デフォルト値の 100 では、カーネルはページキャッシュとスワップキャッシュに関して dentry と inode キャッシュを「公平に」解放しようとします。 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/ページキャッシュ

ページキャッシュは、ファイルや実行可能プログラムからのデータ、つまりファイルまたはブロックデバイスの実際の内容を含むページを保存するキャッシュです。このキャッシュはディスク読み取り回数を減らすために使用されます。値が「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

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

ブロックデバイス --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))

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

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

追加の資料

続きを読む

Red Hat Enterprise Linuxでnftablesを使用する Linux 8

出所： habr.com