4

組み込みシステム、スワップなし、カーネル v2.6.36、メモリ圧縮が有効。

使用率が高いと、すべての RAM がキャッシュに拘束されます。キャッシュは約 70M のメモリを使用していました。ユーザー空間プロセスがメモリを割り当てるとき、問題はありません。キャッシュはそれを放棄します。

しかし、物理的な 5 番目のページを割り当てようとしているように見えるサードパーティのデバイス ドライバーがあり、OOM で失敗します。buddyinfo をざっと見てみると、これが確認できます... 5 番目の注文ページはありません。しかし、キャッシュを削除するとすぐに、十分な量が利用可能になり、デバイス ドライバーは OOM ではなくなります。

したがって、仮想メモリの割り当てはキャッシュドロップをトリガーするように思えますが、物理メモリの割り当てはそうではありませんか? これは意味がありません。メモリがキャッシュに拘束されている場合、カーネル モジュールは OOM を起こす可能性が高く、この動作は、キャッシュがないことによるディスク アクセスの低速化よりも有害であるように思われるからです。

これに対処するためのチューニング パラメータはありますか?

ありがとう！

4

1 に答える 1

2

これが何が起こっているのかです。キャッシュの使用量が多いためにカーネルモジュールがOOMになる理由はまだわかりません。問題は、私たちがアクセスできないサードパーティのコードにあるため、誰が彼らが何をしているのかを知っています。

これが設計によるものであるかどうかは議論の余地があると思います。重要ではないディスクキャッシュが使用可能なすべての空きメモリを取得し、カーネルモジュールをOOMにしてから、IMHO、ディスクキャッシュがカーネルに何かを残す可能性があります。

代わりに、キャッシュを制限することにしました。これにより、カーネルで使用するための「真に空き」メモリが常に残り、キャッシュに拘束された「空き」メモリに依存しなくなります。

/ proc / sys / vm / pagecache_ratioを追加するカーネルパッチがあり、ディスクキャッシュが使用できるメモリ量を設定できます。しかし、それは何らかの理由でカーネルに組み込まれることはありませんでした（特に、ディスクキャッシュがカーネルOOMを引き起こす可能性がある場合は、それは良い考えだと思いました）。しかし、保守性と将来性の理由から、カーネルパッチをいじりたくありませんでした。誰かが1回限りの取引を行っていて、パッチを気にしない場合は、次のリンクを参照してください：http: //lwn.net/Articles/218890/

私の解決策は、カーネルを再コンパイルしてcgroupを有効にし、それを使用して、大量のディスクアクセスを担当するプロセスのグループのメモリ使用量を制限することです（したがって、キャッシュを実行します）。構成を微調整した後、正常に機能しているようです。週末にストレステストを実行したままセットアップを終了し、OOMがまだ発生するかどうかを確認します。

編集

私は自分の答えを見つけたと思います。/ proc / sys /vm/にはVMチューニングパラメーターがあります。この問題に関連する調整可能な設定は、min_free_kbytes、lowmem_reserve_ratio、およびextfrag_thresholdです。

于 2013-02-02T05:40:21.897 に答える