デバイスごとの dirty_ratio

デバイスごとの dirty_ratio

Q：より多くの書き込みキャッシュを得るために高速デバイスを「ホワイトリスト」にする方法はありますか？または、遅いデバイス（または//cifs/pathsなどのリモート「デバイス」）に書き込みキャッシュを使用しないようにしますか？

これを達成するための設定がありますが、必要に応じて機能しません。bdi以下の（「サポートデバイス」）オブジェクトを参照してくださいsysfs。

linux-4.18/documentation/ABI/test/sysfs-class-bdi

最小比(読み書き)

一般的な状況では、各デバイスは、他のデバイスと比較して現在の平均書き込みレートに基づいて、総後書きキャッシュの一部を取得します。

"min_ratio"パラメーターを使用すると、後書きキャッシュの最小割合を特定のデバイスに割り当てることができます。これは、例えば、最小ＱｏＳを提供するのに有用である。

最大比(読み書き)

特定のデバイスが後書きキャッシュの指定された割合以上を使用しないように制限できます。これは、1 つのデバイスが後書きキャッシュの全部または大部分を占有しないようにする場合に便利です。たとえば、NFSマウントが簡単に停止する場合です。

問題は、「この設定は、合計ダーティデータが（ダーティ_背景_比率+ダーティ_比率）/ 2より多い場合にのみ適用されます。これは、プロセス制限を開始したときにダーティデータの量があるためです。次のようにします。現在の書き込みこの制限に大きな影響を与えない唯一の書き込みを入力してください。追加の読書：

• Jan KaraによるLKMLの投稿(2013).
• この回答の最後に「テストケース」があります。
• 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つの可能性は、より具体的な欠陥を再現していることです。カーネル開発者に報告すると、分析して解決策を見つけることもできます。人と交流するのが大好きです。透明ページ以前は解決済み。問題を再現するには、アップストリームカーネルを使用する必要があります。または有料サポート担当者に連絡してください:).

それ以外の場合は、パッチを適用して内部strictlimit設定を公開できます。これはあなたをmax_ratio厳しい限界に陥ります。そのパッチはまだメインラインに適用されていません。十分な数の人がそれを必要とする場合は、パッチを適用することも、パッチの必要性を排除するためのいくつかの作業をお勧めします。

私が心配しているのは、この機能がうまくいくかもしれませんが、うまくいかないかもしれません。十分包含を正当化するのに役立ちます。したがって、私たちは最終的に他の方法でこれらの問題を解決し、この廃止されたレガシー機能を維持し続けます。

私は、これが素晴らしい、完全で、「十分に大きな」問題のセットを解決するのに十分であることを誰かが示せない場合は、パッチ[1]に合格すると思います。人々はどう思いますか？

[1]実際に-mmに入れてメンテナンスするので、次に誰か問題を報告すれば「いや、これしてみて」と言えます。

-アンドリュー・モートン、2013

mm-add-strictlimit-knob-v2.patchそれでも-mmに座っています。人々はダーティキャッシュの自動調整を改善するアイデアを数回言及しました。しかし、私はまだこの分野で多くの仕事を見つけることができませんでした。魅力的な提案は、デバイスごとに5秒の後書きキャッシュを維持することです。しかし、例えば、ＩＯパターンがランダムであるか順次であるかに応じて、デバイスの速度が急激に変化することがある。

分析（ただし結論はありません）

Q：カーネルが超高速ローカルSSDドライブを処理するのと同じ方法で、遅いリモートCIFSデバイスのフラッシュページを処理することに驚きました。

これらの治療法は同じではありません。上記のBDIドキュメントへの参照を参照してください。 「各デバイスには、現在の平均書き込み速度に基づいて、書き込みキャッシュ全体の一部が割り当てられます。」

ただし、これが遅いデバイスが書き込まれる唯一のデバイスである場合は、書き込み書き込みキャッシュ全体を15から20％の間で埋めることができます。

書き込みを開始するデバイスの最大書き込みストレージキャッシュが許可された共有より小さい場合は、「ダーティ制限」コードを少し調整する必要があります。これにより、残りのスペースの一部を使用することができ、遅いデバイスがスペースを解放するのを待つ必要がなくなります。

ドキュメントでは、NFSサーバーが利用できなくなった場合、遅延など、デバイスの速度が予測不能に変更された場合は、min_ratioとmax_ratioの設定を追加することをお勧めします。

問題は、ダーティスロットルが遅いデバイスを制御できず、20％のハード制限を満たすか、それに近づく場合です。

私たちが興味を持っているダーティーコントロールコードはv3.2で再構築されました。紹介はLWN.net記事」IOダーティスロットリングなしまた、発売後、Fengguang WuはLinuxCon Japanで講演しました。プレゼンテーションスライド非常に詳細で有益です。

目標は、より良いIOパターンを可能にするために、BDIへのすべての書き込みを専用スレッドに再委任することです。しかし、それほど直接的ではない制限システムに切り替える必要がありました。せいぜいコードを推論するのが難しくなります。よくテストされていますが、すべての可能な動作メカニズムをカバーしているかどうかはわかりません。

実際にv4.18を見ると明示的な代替コード問題のより極端なバージョンの場合：BDIが次の場合完全反応がありません。他のBDIが進化し続けるように努力していますが、使用可能な書き込みストレージキャッシュの量はさらに制限されます。ビルダーが1つしかない場合でもパフォーマンスが低下する可能性があります。

質問：メモリ不足のため、システムはほとんどの読み取りキャッシュを取り出すときにダーティ（書き込み）キャッシュをフラッシュして回収しようとします。したがって、状況は膨大なローカルディスクI / O完了時間と組み合わせた巨大なCPU iowait、ノンストップ待機中のDの多くのプロセス、完全に応答しないシステムです。システムが空きメモリを解放しないため、OOM キラーは起動しません。 （CIFSにはフラッシュを非常に遅くするバグもあるようです。しかし、ここでは気にしないでください。）

システムがメモリ不足に直面していると言われました。これは非常に難しいケースの例です。 「使用可能な」メモリがなくなると、後書きキャッシュのサイズに負担がかかる可能性があります。 「dirty_ratio」は、実際には「使用可能な」メモリの割合です。これは、空きメモリ+ページキャッシュを意味します。。

これは原作でも現れました。試みがある簡単それ。 「新しいダーティ制限は光機関の制限を避けることはできませんが、睡眠時間を200ミリ秒に制限することができます」と述べています。

「max_ratio」のテストケース

VM/ノートブック/何でも設定すると動作します。いいえ高価なRAMを持っています。dd if=/dev/zero bs=1M of=~/testWatch Write Cacheを実行して使用しますgrep -E '^(Dirty:|Writeback:)' /proc/meminfo。ダーティ+書き込み保存が「設定ポイント」の周りに落ち着くのがわかります。

設定点は17.5％（15％～20％）です。 Linux v4.18の結果は次のとおりです。ここ。正確な比率を表示するには、次のようになります。いいえ総RAMのパーセンテージ; i提案dirty_balance_pages() でトレースポイントを使用します。

max_ratioファイルシステムBDIで異なる値を使用してこのテストを実行しました。予想どおり、書き込みストレージキャッシュを15％未満に制限することは不可能です。

各デバイスのダーティ比を次のように設定できると思います。

echo RATIO > /sys/class/bdi/MAJOR:MINOR/max_ratio

dirty_ratio実験をしてみると「パック」のバランスがかなりよく合うことがわかりました。ページを汚すプロセスには一種の制限があります。 1つのcpプロセスは可能な限りほとんどすべての書き込みキャッシュを簡単に占有できますが、10回の競合プロセスを実行しても書き込みキャッシュ制限（dirty_ratio）にはほとんど到達しません。

したがって、私はすべての問題が私が言及したCIFS関連のバグにあると思います。より多くのプロセスが高速ローカルディスクに書き込む場合、カーネルはCIFS使用量を減らします。ここでは、より多くのプロセスがメモリのみを使用しようとしており、上記のバグのため、カーネルは大規模なCIFS書き込みキャッシュをフラッシュして回収できません。バグでなかった場合、dirty_ratio 30％は問題にならなかったでしょう。