通常のファイルシステムの代わりに/ tmpにtmpfs +非常に大きなスワップパーティションを使用していますか？

Linuxサーバーがあり、予備の500GBディスクパーティションがあります。それをフォーマットして/ tmpに使用したかったのです。サーバーは時々いくつかの大きなデータ処理タスクを実行するため、/ tmpがGBの一時データを保持することがあります。

次に、代わりにそれをスワップパーティションとして追加し、/ tmpにtmpfsをマウントできるというアイデアを得ました。このアイデアは合理的ですか？

サーバーには6 GBのRAMが搭載されているため、ほとんどの場合、/ tmp上のデータはRAMにのみ存在し、明らかに速度が向上します。問題は、/ tmpに10〜20 GBのデータがあるとしたら、システムはどのように機能するのでしょうか。単純に/ tmpをext4パーティションにマウントした場合と比較して、パフォーマンスはどの程度でしょうか？手伝ってくれてありがとう。

編集： tmpfsの使用がRAMの制限に達すると、システムがメモリのスワップアウトを開始することは明らかです。しかし、Linuxはtmpfsデータをスワップアウトし、「通常の」データをRAMに保持するのに十分スマートですか？はいの場合、それは合理的に動作する可能性があると思います。そうでない場合、システム全体が深刻な影響を受けます。

これはグッドアイディア^TMではありません。

あなたは/tmpこのようにマウントされた大きなパーティションで大丈夫です（から/etc/fstab）

tmpfs  /dev/tmp  tmpfs  defaults,nosuid,nodev,noexec,noatime,nodiratime,size=6000M 0 0

そして、外付けドライブを巨大なスワップパーティションとして追加することができます

/dev/sdb1  swap  swap  defaults  0 0

それが限界に達すると、マシンはRAMからディスクにページをスワップし始めます-その時点で、負荷平均は屋根を通り抜け、マシンは停止します。

何らかの方法でSWAPに依存するのは悪い考えです。500GBのドライブを販売し、RAMを購入するだけの方が安上がりです。

要約すれば

/tmp500 GBのディスクを本当に使用したい場合は、500 GBのディスクを、ジャーナリングされていないファイルシステムを使用してマウントし、atimeとdiratimeを無効にします（例：）ext2。それはされているマシンを扱うよりも実質的に速くなりSWAPINGの

これは合理的な考えかもしれません。

実際のファイルシステムを/ tmpに置くとオーバーヘッドが発生します。ファイルシステムはシステム障害が発生した場合にディスク上のデータが破損しないようにするために非常に長い時間がかかるためです。ブート時にクリーンアップされる/ tmpの場合、それは明らかに単なるオーバーヘッドです。tmpfsを使用すると、そのオーバーヘッドを回避できます。

一方、ファイルシステムは、ファイルがディスク上でアクセス時間を最適化するように編成されていることも確認します。つまり、ファイルシステムは断片化を回避します。通常の順次ファイルアクセスでは、（ほとんどの場合）順次ディスクアクセスが発生します。これは、ランダムアクセスよりも効率的です。この効果は、SSDよりも回転しているハードディスクでより顕著になります。swap + tmpfsの組み合わせではこれを簡単に行うことができません。これは、swapがどのメモリがどのファイルに属しているかを認識しておらず、tmpfsがページが物理メモリまたはディスクにどのようにマップされているかを認識していないためです。ただし、大きなファイルの場合は、tmpfsとswapの両方が連続した状態を維持しようとするため、うまく機能するはずです。少なくとも、スワップに多くの空き領域がある場合（そうでない場合は断片化が発生します）、書き込みが遅くなるので、スワップアウトされる可能性があります。

したがって、結論は次のとおりです。状況によって異なります。両方のオプションを試して、どちらが最適かを確認する必要があります。

tmpfsをマウントするときは、サイズを明示的に設定することを忘れないでください。デフォルトは物理RAMの半分なので、ちょうど3GBです。

これは、通常にデータがあまりない場合に適していますが/tmp、限られた期間、無限のギガバイトを消費することがあります。問題は、Linuxスワップシステムがユースケースを正しく理解していないためです。通常、プログラムページよりもキャッシュのダンプまたはスワッピングが優先されますが、これは実際には役立ちません。cgroupを使用して目標を達成することは可能かもしれませんが、スクラッチデータがプログラムメモリに保持されている場合ですが、この場合のcgroupの構成方法がわかりません（FUSE tmpfsを使用できると思います...） 。幸い、それは必要ありません。zramとバッキングデバイスを使用して、目的の動作を得ることができます。

zram-init圧縮されたramブロックデバイスであるzramの設定を自動化するプログラムです。通常、zram-init設定に/tmpはzramとしてマウントするための例があります。次のようなものになります

type0=/tmp
flag0= 
size0=524288 # 500G of logical space
mlim0=2G # 2G of memory
back0=/dev/loop0 # (or /dev/sdxN, your large slow drive)
notr0= 
maxs0=4 # maximum number of parallel processes for this device
algo0=zstd 
labl0=tmp # the label name
uuid0= 
args0= 

これにより、/ tmpに書き込まれたものはすべて圧縮されてメモリに格納されます。通常の圧縮は、約50％です。最大で2Gの物理メモリを消費します。物理メモリが不足すると、最も古いファイルが取得され、圧縮されたままバッキングデバイスにプッシュされます。ファイルを圧縮および解凍するためにいくらかのCPUオーバーヘッドが発生しますが、これは通常、IOの減少によって相殺されます。

同様の設定をcgroupと組み合わせて使用​​すると、システム全体のパフォーマンスに悪影響を与えることなく特定のプロセスをスワップできます。