☰

/dev/shmに書きすぎると、スワップファイルが自動的に参加します。

tag-icon • tag-icon linux swap shared-memory
/dev/shmに書きすぎると、スワップファイルが自動的に参加します。

今日のテキスト分析プログラミング。私のプログラムは/dev/shmに約4,500万個の小さな一時ファイルを書きます。そのサイズは177.0GBと推定されます。次のステップ以降すぐに削除します。問題は、ホストコンピュータに128 GBの物理RAMがあり、物理RAMが不足していることです。

いいですね。 Q：/dev/shmに書き込むとスワップが自動的に開始されますか？合計スワップスペースが239GB、RAMが128GBであるため十分です。

2番目の質問：現在/ dev / shmに100Gが割り当てられています。 /dev/shmを事前に177G（または安全のために190G）に（物理RAMを超えて）過度に割り当てる必要がありますか？それとも、スワップは現在割り当てられている100G以上の使用量を自動的に処理するため、/dev/shmサイズを事前に190Gに設定する必要はありませんか？

ちなみに、私はすでに6000万個のinodeを持っています。これはいいですね。ところで、私はまた、Linux ext4がディスク上の約1,050万個のファイルで失敗することを発見しました。これは繰り返されますが、決定論的ではありません。 Pythonファイルの書き込みに関する限り、設計は非常に遅くなるため、これはタイムアウトの問題のようです。おそらく、ファイルシステムinodeのテーブル挿入のための線形時間複雑度アルゴリズムとPythonファイル書き込みインフラストラクチャにかかる時間が長すぎると、より多くのファイルが生成されます。 、名目上20億のファイル数制限にもかかわらず。ここでは、SSDと回転ディスクは同じように動作し、違いはありません。 inodeも大丈夫で、空きスペースも大丈夫です。タイムアウトのためにシステムがシャットダウンし、実際のファイルシステムで常にOSErrorが発生するだけです（それで/ dev / shmに移動します）。

このホストは：

$ uname -a
Linux ga-HP-Z820 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ df -i /dev/shm
Filesystem       Inodes IUsed    IFree IUse% Mounted on
tmpfs          60000000     1 59999999    1% /dev/shm
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ df -BG /dev/shm
Filesystem     1G-blocks  Used Available Use% Mounted on
tmpfs               100G    0G      100G   0% /dev/shm
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$

追加情報：

ITはここに言う

tmpfsインスタンスが大きすぎると、OOMハンドラはそのメモリを解放できないため、システムがデッドロックに陥ります。

。だから私はしないと思います！ ！ ！https://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/tmpfs.txt

だから私は交換がすべてのことを処理するようにしておくかどうかを調べるために実験をすることにしました。今のように実行してみてください。私のファイルが/ devshmに割り当てられたサイズを超えるようにし、残りの部分はスワップを実行します。

答え1

/dev/shmにあまりにも多くのファイルを書くと、何が起こるのか見てみましょう。

OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/fastssd/bot_subreddit_recom/write_user_docs.py", line 85, in <module>
    f.write(subreddits)
OSError: [Errno 28] No space left on device
inFile: RC_2018-01-02
outDir: tmp
outputToScreenOnly: 0
OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/fastssd/bot_subreddit_recom/write_user_docs.py", line 85, in <module>
    f.write(subreddits)
OSError: [Errno 28] No space left on device

ファイルを入力してから33日で、上記のように「スペース不足」状態になりました。

>>> 36.*33/12
99.0

したがって、約99GB（100GBに非常に近い）のファイルが「残りのスペースなし」エラーが発生する場所です。これは正確に100Gに設定された/ dev / shmデバイスのサイズです。これは、必要に応じて実際にスワップを使用できないことを意味します。残念ながら、これは/ dev / shmが使い果たされ、メモリが不足しているときにスワップを仮想メモリとして使用し続けることができないことを示しています。今、私たちはこの実験を通してそれを知りました。 /dev/shm が動作するには物理的な物理 RAM だけが必要であり、スワップとも呼ばれる仮想 RAM は /dev/shm にまったく役に立ちません。

得られた情報で利益を得ることができる他の人と共有するためにこの回答を投稿します。

関連情報