書き込みストレージキャッシュ(「ダーティ」)はdirty_Background_ratioよりはるかに小さいものに制限されているようです。その限界は何ですか?この制限はどのように計算されますか?

書き込みストレージキャッシュ(「ダーティ」)はdirty_Background_ratioよりはるかに小さいものに制限されているようです。その限界は何ですか?この制限はどのように計算されますか?

私はLinuxをテストしてきました4.18.16-200.fc28.x86_64。によると、free -h私のシステムの総RAMは7.7Gです。

sysctlのデフォルト値がありますvm.dirty*dirty_background_ratio10、20dirty_ratioです。私が読んだことによれば、LinuxはRAMの10%である0.77Gに達するとダーティキャッシュを書き始めると予想されます。ダーティキャッシュがRAMの20%(1.54G)に達したら、バッファリングされたwrite()呼び出しをブロックする必要があります。

私は走ってフィールドをdd if=/dev/zero of=~/test bs=1M count=2000見ました。命令実行中の値は約0.5Gに安定します。これはダーティバックグラウンドしきい値(0.77G)よりはるかに少ないです!どうやって?私は何を見逃していますか?dirtyatopdddirty

dirty_expire_centisecs3000なのにその理由はないようです。私はそれが限界であることを確認するためにdirty_expire_centisecs100、10まで降ろそうとしました。結果は変わらなかった。dirty_writeback_centisecsdirty

私はもともとこの調査の一環として、以下の観察内容を書きました。2013年に「USBフラッシュドライブの停止」の問題が発生したのはなぜですか?既存の「I / Oダーティスロットリングなし」コードがこの問題を解決できないのはなぜですか?


私が知る限り、2つのしきい値(15%= 1.155G)の間の中間で、write()呼び出しが曲線上で調整(遅延)し始めます。ただし、この制限以下では待ち時間は増加しません。ダーティページを生成するプロセスは「自由に実行」することができる。

私が理解したのは、この制限の目的は、ダーティキャッシュを15%以上に保ち、20%のハード制限に達するのを防ぐことです。すべての状況で保証を提供するわけではありません。しかし、私はddコマンドを使って簡単なケースをテストしています。デバイスが実装する書き込み速度と一致するようにwrite()呼び出し速度を制限する必要があると思います。

(複雑な例外があるため、単純な保証はありません。たとえば、制限コードは遅延を最大200ミリ秒に制限しますが、プロセスの目標速度制限が1秒あたり1ページ未満の場合はそうではありません。場合には厳しい速度制限が適用されます。 .)

  • ドキュメント/sysctl/vm.txt- Linux v4.18
  • I/Oダーティスロットリングなし- 2011 LWN.net。
  • (ダーティ_背景_比率+ダーティ_比率)/ 2合計ダーティデータは...プロセス制限を開始したときのダーティデータの量です。ジェーン・カラ、2013

  • ユーザーは、グローバル(バックグラウンド+ダーティ)/ 2 = 15%のしきい値を超えると、アプリケーションが制限され、約17.5%のバランスをとることがわかります。パッチの前にはダーティメモリを20%に制限するのが動作でした。

    --143dfe8611a6 コミット、"書き換え:IOなしでBalance_dirty_pages()

  • デフォルトでは、メモリ管理サブシステムはダーティページをシステムメモリの最大15%に制限しようとします。必要に応じて、ページが汚れる速度とページを整理できる速度に合わせて多数のページをダーティ化するプロセスを制限する Balance_dirty_pages() という「魔法関数」があります。 "——書き換えグループと制御グループ、2015 LWN.net。

  • バランスのとれたページ()Linux 4.18.16。

ベストアンサー1

見ているドキュメント/sysctl/vm.txt:

汚い料金

以下の内容が含まれています。利用可能なページと回収可能なページを含む、合計使用可能なメモリ比、ディスクを作成するプロセスがダーティデータを書き込んで開始するページの数。

使用可能な合計メモリーが合計システム・メモリーと同じではありません。

使用可能なメモリは次のように計算されます。グローバルダーティーメモリ()。これは、使用可能なメモリ量にページキャッシュを追加したのと同じです。交換可能なページ(匿名メモリ割り当て、ファイルでサポートされていないメモリなど)は含まれません。

この動作は次に適用されます。Linux 3.14(2014)。この変更前に、交換可能ページはglobal_dirtyable_memory()の合計に含まれていました。

コマンド実行時の統計の例dd:

$ while true; do grep -E '^(Dirty:|Writeback:|MemFree:|Cached:)' /proc/meminfo | tr '\n' ' '; echo; sleep 1; done
MemFree:         1793676 kB Cached:          1280812 kB Dirty:                 4 kB Writeback:             0 kB
MemFree:         1240728 kB Cached:          1826644 kB Dirty:            386128 kB Writeback:         67608 kB
MemFree:         1079700 kB Cached:          1983696 kB Dirty:            319812 kB Writeback:        143536 kB
MemFree:          937772 kB Cached:          2121424 kB Dirty:            312048 kB Writeback:        112520 kB
MemFree:          755776 kB Cached:          2298276 kB Dirty:            389828 kB Writeback:         68408 kB
...
MemFree:          136376 kB Cached:          2984308 kB Dirty:            485332 kB Writeback:         51300 kB
MemFree:          101340 kB Cached:          3028996 kB Dirty:            450176 kB Writeback:        119348 kB
MemFree:          122304 kB Cached:          3021836 kB Dirty:            552620 kB Writeback:          8484 kB
MemFree:          101016 kB Cached:          3053628 kB Dirty:            501128 kB Writeback:         61028 kB

最後の行には、約3,150,000kBの「使用可能な」メモリが表示され、合計562,000kBのデータが再書き込みまたは再書き込みされるのを待っています。 17.8%です。比率はこのレベルの周りで変動しているように見えますが、通常15%に近いです。 編集する:この数字はより近いようですが、このアプローチを信頼しないでください。これはまだ正しい計算ではなく、非常に誤った結果をもたらす可能性があります。フォローアップの表示ここ


これはとても難しいと思います。

私は以下があることに気づいた。Balance_dirty_pages() のトレースポイント、「調整アルゴリズムのダイナミクス解析」に使用できます。だから私は以下を使用しましたperf

$ sudo perf list '*balance_dirty_pages'

List of pre-defined events (to be used in -e):

  writeback:balance_dirty_pages                      [Tracepoint event]
...
$ sudo perf record -e writeback:balance_dirty_pages dd if=/dev/zero of=~/test bs=1M count=2000
$ sudo perf script

表示された内容dirty(4096バイトページで測定)が予想より低かったsetpoint。コードを追跡しましたが、これは...freerunに設定されているトレースポイント定義に似た低い値が必要であることを意味します。(thresh + bg_thresh) / 2global_dirtyable_memory()

おすすめ記事