☰

/dev/shmの空きメモリー内のファイルを切断しませんか？

tag-icon • tag-icon linux inode tmpfs memory-leaks
/dev/shmの空きメモリー内のファイルを切断しませんか？

狂気のように感じたり、tmpfsは長期間の使用には適していません。

私のワークロードは、/dev/shm/[一部のディレクトリツリー]にファイルを非常にすばやく作成してリンクを解除します。 Linuxスラブの使用量（サイズ64とサイズ128）は、inodeの割り当て/リンク解除によって線形に増加し、絶対にダウンしません（メモリはmeminfoを介して回収不可能としてリストされ、slabinfoには何百万ものライブオブジェクトが表示されます）。

このメモリは決して回収されず、続行が許可されるとOOMが発生します。唯一の修正方法は、/dev/shmをアンインストールして再インストールすることです。

数年前に他のユーザーがこの質問をしましたが、答えは実際に問題の問題をカバーしていません（/dev/shm の操作によりオーバーフローが発生しました。）。

これは単にtmpfsの設計決定ですか、それとも別のものがありますか？インデックスノードが一度割り当てられると解放されないことは本当に残念です。

タイムライン：このプロセスは一度に1つずつ500万個のファイルを作成し、作成後すぐに各ファイルを切断します。この時点で、すべてのユーザープロセスが終了します。メモリ使用量は/ dev / shmにまだ500万のinodeがあるように見えますが、df -iとdf -hは/ dev / shmが本質的に空であることを報告します。プロセスループをさらに繰り返すと、システムメモリが完全に不足し、OOMが発生するまでメモリ使用量が直線的に増加します。

編集：後でこの問題が発生した場合、これは私が実行している古いカーネル（SLES 11、2.6.32など）の成果物であるようです。最新のカーネルでは問題を再現できません。

答え1

これは、この特定のシステムで実行されている古いカーネルのバグのようです。最新のカーネルパッチがインストールされている最新のRHEL 6システムでは、これを再現できません。

答え2

わかりやすくするために、コメントで議論した内容について、ある程度スクリプトテストを追加しました。この時間はカーネル 4.7.2問題が発生しない場合：

$ cd /dev/shm
$ free
              total        used        free      shared  buff/cache   available
Mem:        1794788      673948      873668       19300      247172      963316
Swap:       2097148           0     2097148
$ for i in `seq 100000`; do touch node$i; done
$ ls -1|wc -l  # oops, there are extra three pulseaudio files here
 100003
$ free
              total        used        free      shared  buff/cache   available
Mem:        1794788      738240      811944       19300      244604      890184
Swap:       2097148           0     2097148

さて、メモリスペースを確保しました。しかし、rmクリア

$ rm node*
$ free
              total        used        free      shared  buff/cache   available
Mem:        1794788      671484      896524       19300      226780      965884
Swap:       2097148           0     2097148

一部のキャッシュを同時に削除したため、このゲームは完璧ではありません。しかし、この小さな実験の始めと終わりでは、利用可能なメモリ量とキャッシュ内のメモリ量は同じでした。

はい。問題は以前のカーネルバージョンでのみ発生します。これはバグがあったが修正されたことを示します。

関連情報