/dev/shm の操作によりオーバーフローが発生しました。

/dev/shm の操作によりオーバーフローが発生しました。

/dev/shmで同様の操作を数万回繰り返しますが、それぞれディレクトリを作成し、ファイルを書き込んで削除します。私の仮定は、実際にディレクトリを作成してその場所から削除することであるため、メモリ消費量が非常に低くなければなりませんでした。しかし、使用量がかなり高く、最終的にメモリオーバーフローが発生することがわかりました。だから私の質問は次のとおりです。

mkdir /dev/shm/foo
touch /dev/shm/foo/bar
[edit] /dev/shm/foo/bar
....
rm -rf /dev/shm/foo

結局、メモリオーバーフローが発生しますか?これが実際にそうであれば、その場で削除されるように見えるので、なぜですか?

メモ:何万もの同様のタスクがあります。

ベストアンサー1

df -h /dev/shm気になります。このアプリケーションを実行するとRAMの使用量はどのように表示されますか?

一時ファイルシステム

デフォルトでは、通常はシステムの物理メモリ量の50%に設定されています。これはここに録音してくださいkernel.orgのtmpfsファイルシステム文書にあります。マニュアルページにも記載されていますmount

から抜粋インストールマニュアルページ

このインスタンスの最大 inode 数。デフォルトは、物理RAMページ数の半分、または(高域を持つシステムでは)lowmem RAMページ数の半分のいずれか小さい方です。

確認する

私の8GB RAMノートブックには次の設定があります/dev/shm

$ df -h /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 3.9G  4.4M  3.9G   1% /dev/shm

どうなりますか?

私の考えでは、最初にRAMの50%を割り当てることに加えて、時間の経過とともに実際にメモリの合計50%を消費し、/dev/shmRAMの残りの50%でスペースを増やすようです。交換エリアに入ります。 。

tmpfsvsのもう1つの機能は、必要に応じてスワップに入れることができることramfsです。tmpfs

から抜粋geek.com

                    Table: Comparison of ramfs and tmpfs

Experimentation                          Tmpfs                Ramfs
---------------                          -----                -----
Fill maximum space and continue writing  Will display error   Will continue writing
Fixed Size                               Yes                  No
Uses Swap                                Yes                  No
Volatile Storage                         Yes                  Yes

最終的にこれはRAMに実装されているファイルシステムなので、両方のように動作すると予想されます。私は、ファイル/ディレクトリが削除されると、一部の物理メモリページをinodeテーブルとして使用し、そのファイル/ディレクトリが消費するいくつかの物理スペースを使用するということです。

一般に、HDDのスペースを使用するときは、実際に物理スペースを解放するのではなく、特定のファイルが消費するスペースを使用できることを示すinodeテーブルのエントリのみを使用できます。

したがって、RAMの観点から見ると、ファイルが消費するスペースはメモリのダーティページにすぎません。したがって、時間の経過とともに忠実に交換されます。

tmpfs提供するファイルシステムで使用されている実際のRAMをクリーンアップするために特別な作業を実行するかどうかはわかりません。人々が自分のシステムで実行している作業を「リサイクル」するのに15分以上かかるという言及をいくつかのフォーラムで見たことがあります/dev/shm

おそらく私が見つけたこの論文のtmpfsタイトルは次のようになりました。tmpfs: 仮想メモリファイルシステムこれがより低いレベルでどのように実装されるか、およびVMMに関してどのように機能するかをより明確に説明します。このドキュメントはSunOS用に特別に書かれていますが、いくつかの手がかりを含めることができます。

実験

/dev/shm以下の人為的なテストは、自己清掃が可能であることを示しています。

実験#1

単一のファイルを含むディレクトリを作成し、そのディレクトリを1000回削除します。

初期状態/dev/shm
$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5500   3988244   1% /dev/shm
ファイルでいっぱい
$ for i in `seq 1 1000`;do mkdir /dev/shm/sam; echo "$i" \
      > /dev/shm/sam/file$i; rm -fr /dev/shm/sam;done
最終状態は/dev/shm
$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5528   3988216   1% /dev/shm

実験#2

50MBファイルを含むディレクトリを作成し、そのディレクトリを300回削除します。

50MBのランダムジャンクファイルで埋める
$ start_time=`date +%s`
$ for i in `seq 1 300`;do mkdir /dev/shm/sam;                     \
   dd if=/dev/random of=/dev/shm/sam/file$i bs=52428800 count=1 > \
   /dev/shm/sam/file$i.log; rm -fr /dev/shm/sam;done              \
   && echo run time is $(expr `date +%s` - $start_time) s

...
8 bytes (8 B) copied, 0.247272 s, 0.0 kB/s
0+1 records in
0+1 records out
9 bytes (9 B) copied, 1.49836 s, 0.0 kB/s
run time is 213 s
最終状態は/dev/shm

繰り返しますが、消費されるスペースは著しく増加しません/dev/shm

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5500   3988244   1% /dev/shm

結論として

上記の内容を何度も実行しても何の/dev/shm効果もないようです。それで、/dev/shmあなたが説明する方法で使用することに問題はないと思います。

おすすめ記事