デバイスごとのdirty_ratio
最近、CIFSファイルシステムに書き込んだという理由だけでほぼ完全にハングしたRHEL7.2を調べました。 dirty_ratio = 30のデフォルト設定とcifsがキャッシュされている場合（読み取りと書き込みの両方）、これらのダーティページはほとんどcifsのものでした。
メモリ不足の下で、システムが読み取りキャッシュの大部分を再利用すると、システムは頑固にダーティ（書き込み）キャッシュをフラッシュして再利用しようとしました。そのため、状況は、優れたローカルディスクI/O完了時間、Dの無停電待機の多くのプロセス、および完全に応答しないシステムを伴う巨大なCPUiowaitでした。 wasシステムが提供していなかった空きメモリがあるため、OOMキラーは関与しませんでした。 （CIFSには、フラッシュを信じられないほど遅い速度にクロールするバグもあると思います。ただし、ここでは気にしないでください。）
私は、カーネルが超高速のローカルSSDドライブとまったく同じ方法で、低速のリモートCIFSボックスへのページのフラッシュを処理していることに驚きました。 dirty_ratioバッグを1つ持つのは無意味です。すぐに、RAMの30％に最も遅いデバイスからのダーティデータが含まれている）という状況になります。お金の無駄使い。
状況は再現可能です。 dirty_ratio = 1を設定すると、問題が完全に解決されます。しかし、cifsマウントを使用しているという理由だけで、ローカルディスクのキャッシュを犠牲にする必要があるのはなぜですか？
一部のデバイスのキャッシュを完全に無効にするか、vm.dirty_ratioを非常に低い値に設定する以外に、高速デバイスを「ホワイトリストに登録」して書き込みキャッシュを増やす方法はありますか？または、低速のデバイス（または// cifs/pathのようなリモートの「デバイス」）が使用する書き込みキャッシュを少なくするために？
RHEL7.2のカーネルバージョンは3.10.0-327と呼ばれます。 （3.10.0に基づいていますが、数年分のバックポートが含まれています）。
デバイスごとのdirty_ratio
Q：高速デバイスを「ホワイトリストに登録」して書き込みキャッシュを増やす方法はありますか？または、低速のデバイス（または// cifs/pathのようなリモートの「デバイス」）が使用する書き込みキャッシュを少なくするために？
これにはいくつかの設定がありますが、期待したほど効果的ではありません。 bdiのsysfs（「バッキングデバイス」）オブジェクトを参照してください。
linux-4.18/Documentation/ABI/tests/sysfs-class-bdi
min_ratio （読み書き）
通常の状況では、各デバイスには、他のデバイスと比較した現在の平均書き込み速度に関連する合計ライトバックキャッシュの一部が与えられます。
'min_ratio'パラメータを使用すると、ライトバックキャッシュの最小パーセンテージを特定のデバイスに割り当てることができます。たとえば、これは最小のQoSを提供するのに役立ちます。
max_ratio （読み書き）
特定のデバイスがライトバックキャッシュの指定されたパーセンテージ以下を使用するように制限できます。これは、1つのデバイスがライトバックキャッシュのすべてまたはほとんどを使用することを回避したい状況で役立ちます。たとえば、スタックしがちなNFSマウントの場合です。
キャッチは、「この設定は、合計で（dirty_background_ratio + dirty_ratio）/ 2を超えるダーティデータがある場合にのみ有効になります。これは、プロセスの抑制を開始したときのダーティデータの量です。制限は現在書き込まれている唯一のものであり、制限は大きな影響を及ぼしません。」参考文献：
- Jan KaraによるLKML投稿 （2013）。
- この回答の最後にある「テストケース」。
- commit 5fce25a9df48 v2.6.24で。 「システムに十分なスペースがある場合は、bdi制限の違反を許可します。合計制限の半分に達すると、bdi制限の適用を開始します...」これは、デバイスごとに内部を追加した同じカーネルリリースの一部です。制限」。したがって、プレリリースv2.6.24-rc1と-rc2を除いて、「制限」は常にこのように機能していました。
簡単にするために、30％の設定を無視し、デフォルトのdirty_background_ratio = 10およびdirty_ratio = 20を想定します。この場合、システム全体が15％ポイントに達するまで、プロセスは遅延なくページをダーティすることができます。
Q：状況は再現可能です。 _
dirty_ratio = 1_を設定すると、問題は完全に解決されます。
：-/
これは、LWN.netが記事を書いた「有害なUSBスティックストールの問題」に似ているように聞こえます。残念ながら、この特定の記事は 誤解を招く です。非常に混乱していたため、報告された問題とは異なる問題が発生しました。
1つの可能性は、より具体的な欠陥を再現していることです。カーネル開発者に報告できれば、彼らはそれを分析して解決策を見つけることができるかもしれません。 透明なhugepages との相互作用のように 解決済み でした。アップストリームカーネルを使用して問題を再現することが期待されます。または、有料サポートの連絡先にご相談ください:)。
それ以外の場合は、内部のstrictlimit設定を公開するために適用できるパッチがあります。これにより、_max_ratio_を厳密な制限に変更できます。パッチはメインラインに適用されていません。十分な数の人がこれの必要性を示した場合、パッチが適用されるか、パッチの必要性を取り除くための作業が促進される可能性があります。
私の懸念は、潜在的に有用である一方で、その機能がその包含を正当化するのに十分に十分に有用ではないかもしれないということです。したがって、他の方法でこれらの問題に対処することになり、この廃止されたレガシー機能を維持することになります。
誰かがこれが「十分に大きい」一連の問題に対して適切で完全で十分であることを示すことができない限り、私はパッチをパスするだろうと思っています[1]。人々はどう思いますか？
[1]実は、-mmで貼り付けて維持するので、次回誰かが問題を報告したときは、「ねえ、これを試してみて」と言うことができます。
_mm-add-strictlimit-knob-v2.patch_はまだ-mmに座っています。数回、人々はダーティキャッシュをより良く自動調整することについてのアイデアに言及しました。しかし、私はそれについて多くの仕事を見つけていません。魅力的な提案は、デバイスごとに5秒相当のライトバックキャッシュを保持することです。ただし、デバイスの速度は突然変化する可能性があります。 IOパターンがランダムかシーケンシャルかによって異なります。
分析（ただし結論はありません）
Q：カーネルが超高速ローカルSSDドライブとまったく同じ方法で、低速のリモートCIFSボックスへのページのフラッシュを処理していることに驚きました。
これらはまったく同じようには扱われません。上記のBDIドキュメントからの引用を参照してください。 「各デバイスには、現在の平均書き込み速度に関連する合計ライトバックキャッシュの一部が与えられます。」
ただし、これにより、低速デバイスのみが書き込まれる場合、低速デバイスが全体のライトバックキャッシュを15〜20％のマークまで埋めることができます。
最大ライトバックキャッシュの許容シェアよりも少ないデバイスへの書き込みを開始する場合、「ダーティスロットリング」コードはある程度の余裕を持たせる必要があります。これにより、残りのマージンの一部を使用できるようになり、低速のデバイスがスペースを空けるのを待つ必要がなくなります。
ドキュメントでは、NFSサーバーが利用できないときのストールなど、デバイスの速度が予期せず変化する場合に備えて、min_ratioとmax_ratioの設定が追加されたことが示唆されています。
問題は、ダーティスロットルが低速デバイスの制御に失敗し、20％のハード制限まで（またはそれに近い）満たすことができた場合です。
私たちが興味を持っているダーティなスロットルコードは、v3.2で再形成されました。紹介については、LWN.netの記事 " IO-less dirty throttling "を参照してください。また、リリース後、FengguangWuはLinuxConJapanで発表しました。彼の プレゼンテーションスライド は非常に詳細で有益です。
目標は、BDIのすべてのライトバックを専用スレッドに委任して、IOのパターンを大幅に改善することでした。しかし、彼らはまた、より直接的なスロットルシステムに変更しなければなりませんでした。せいぜい、これはコードを推論するのを難しくします。十分にテストされていますが、考えられるすべての運用体制を網羅しているかどうかはわかりません。
実際、v4.18を見ると、問題のより極端なバージョンには 明示的なフォールバックコード があります。1つのBDIが完全にである場合-）応答しません。他のBDIが引き続き前進できることを確認しようとしますが、...使用できるライトバックキャッシュの量がはるかに制限されます。ライターが1つしかない場合でも、パフォーマンスが低下する可能性があります。
Q：メモリ不足の場合、システムが読み取りキャッシュの大部分を再利用すると、システムは頑固にダーティ（書き込み）キャッシュをフラッシュして再利用しようとしました。そのため、状況は、優れたローカルディスクI/O完了時間、Dの無停電待機の多くのプロセス、および完全に応答しないシステムを伴う巨大なCPUiowaitでした。システムが提供していない空きメモリがあったため、OOMキラーは関与しませんでした。 （CIFSには、フラッシュを信じられないほど遅い速度にクロールするバグもあると思います。ただし、ここでは気にしないでください。）
あなたはあなたのシステムがメモリプレッシャーにさらされていたと言います。これは、非常に困難なケースの一例です。 「使用可能な」メモリがダウンすると、ライトバックキャッシュのサイズに圧力がかかる可能性があります。 「dirty_ratio」は、実際には「使用可能な」メモリのパーセンテージです これは空きメモリ+ページキャッシュを意味します 。
このケースは、元の作業中に気づかれました。 緩和 それを試みる試みがあります。 「新しいダーティ制限は、軽いダーティアーの抑制を回避することはできませんが、スリープ時間を200msに制限する可能性があります」と書かれています。
「max_ratio」のテストケース
VM /ラップトップ/何でも、notには高価な大量のRAMがありません。実行_dd if=/dev/zero bs=1M of=~/test_、およびgrep -E '^(Dirty:|Writeback:)' /proc/meminfoで書き込みキャッシュを監視します。dirty+ writebackが「セットポイント」の周りに落ち着くのを確認する必要があります。
設定値は17.5％で、15％と20％の中間です。 Linux v4.18での私の結果は ここ です。正確なパーセンテージを確認したい場合は、比率がRAM全体のパーセンテージではないことに注意してください。 I suggest あなたはdirty_balance_pages（）でトレースポイントを使用します。
このテストは、ファイルシステムのBDIで_max_ratio_のさまざまな値を使用して実行しました。予想どおり、ライトバックキャッシュを15％ポイント未満に制限することはできませんでした。
実験した後、私はそれを見つけましたdirty_ratio「バッグ」はかなり適切にバランスが取れています。ページを汚すプロセスはどういうわけか制約されています。 1つのcpプロセスは、可能な限りほとんどすべての書き込みキャッシュを簡単に使用できますが、10個の競合するプロセスをバーストで実行しても、書き込みキャッシュの上限（dirty_ratio）に達することはめったにありません。
したがって、すべての問題は、私が言及したCIFS関連のバグに起因すると考えています。より多くのプロセスが高速ローカルディスクに書き込みたい場合、カーネルはCIFSに使用する量が少なくなります。ここでは、より多くのプロセスがメモリを使用することを望んでおり、カーネルはこのバグのために大きなCIFS書き込みキャッシュをフラッシュおよび再利用できませんでした。おそらく、バグでなければ、30％のdirty_ratioは問題にはなりません。
デバイスごとのダーティ率の比率は、次の方法で設定できると思います。
echo RATIO > /sys/class/bdi/MAJOR:MINOR/max_ratio