I/O 操作中にプログラムが大量のメモリを消費しますが、これは I/O 操作を大量に実行することによる副作用です。direct_io を使用してプログラムを実行すると、メモリの問題は解消されますが、プログラムがジョブを完了するまでの時間は 4 倍以上になります。
バッファ キャッシュ (I/O 操作中に使用されるカーネル バッファ) の最大サイズを減らす方法はありますか? できればカーネル ソースを変更せずに行うと良いでしょう。
dirty_bytes などを減らすことを試みました/proc/sys/vm/。しかし、目立った違いはないようです。
更新:echo 1 > /proc/sys/vm/drop_caches echo 2 > /proc/sys/vm/drop_caches echo 3 > /proc/sys/vm/drop_caches
プログラム実行中に使用すると、使用されるメモリの量が一時的に削減されます。
ページキャッシュ、dentry、iノードを常に解放するのではなく、何らかの方法で制限することはできますか? そうすれば、おそらく問題は解決するでしょう。
これまで気付かなかったのですが、問題はパーティション分割だけでなく、すべての I/O 操作で発生します。Linux は、利用可能なメモリがほぼ最大になり、空きメモリが 4 MB になるまで、I/O を通過するすべてのものをキャッシュしているようです。つまり、I/O 用にキャッシュできるメモリの量には、何らかの上限があるということです。しかし、それがどこにあるかわかりません。かなり切羽詰まっています。カーネル ソースのどこかで 2 で割ることができなければ、喜んでそうします。
2016 年 12 月 12 日更新: 修正は諦めましたが、あることが私の注意を引き、この問題を思い出しました。家には古くて故障した HDD があり、それを使って何かをしようとすると、ものすごい勢いでリソースを浪費します。
これは単に HDD が故障しただけという可能性はありますか? 問題の HDD は、私の問題が発生してから 1 か月以内に故障しました。この場合、答えは出ています。
答え1
あなたが尋ねたようにプログラム、あなたは使うことができますcグループ:
メモリ制限（たとえば 50 GB、CPU などの他の制限もサポートされています。例では CPU も記載されています）を持つ、group1 のような名前の cgroup を作成します。
cgcreate -g memory,cpu:group1
cgset -r memory.limit_in_bytes=$((50*1024*1024*1024)) group1
次に、アプリがすでに実行されている場合は、アプリをこの cgroup に追加します。
cgclassify -g memory,cpu:group1 $(pidof your_app_name)
または、この cgroup 内でアプリを実行します。
cgexec -g memory,cpu:group1 your_app_name