メモリ不足のジョブを実行し、スワップのために書き込みを開始しました。スワップスペースは25GB、RAMは1TBです。
スワップ領域が11GBまでいっぱいで作業を停止したため、まだ50%が空いていました。
OOM シャットダウン操作が発生しなかったため、すべてが発生する前と同じように正常に動作しています。
現在、スワップスペースは8GBしか使用していません(作業を中断した後、3GBが消去されました)、ますます減っています。しかし、確認してみると、vmstat
両方si
ともスワップに入って行くことは何もありませんかso
?0
どうやってこれができますか?
free -lm
total used free shared buff/cache available
Mem: 1031757 475637 49100 63 507019 553720
Low: 1031757 982657 49100
High: 0 0 0
Swap: 25767 8272 17495
に空き容量があるので、40GB
実行中のジョブが今ではなく後で終了することを期待する必要がありますかRAM
?使用されたスペースが使用可能なスペースより少なくて大丈夫に見えますが、まだ発動されないようにするのかわかりません。OOM
8GB
swap
40GB
RAM
OOM
数ヶ月前、OOM
トリガーされたときにすべてのジョブが終了し、スワップスペース25GB
(すべていっぱい)が使用されてから10分後に発生しました0GB
。ところが、このような場合には整理するのに一日かかりますが2-3 GB
、swap.
これがランニング中の職業に悪いニュースでしょうか?
私が実行しているタスクが今ではなく、後で空きスワップスペースに達してシャットダウンを0 GB
引き起こしたときに終了する危険にさらされていると思いますか?OOM
それでは、どのようにこのようなことが起こらないようにすることができますか?
助けてくれてありがとう。
答え1
vmstat
パラメータがない場合は、再起動後の平均値が表示されます。スワップイン/アウトはブロック/秒で表示されるため、合理的な稼働時間がある場合はゼロで表されるのは驚くべきことではありません。
これで、スワップに含まれるメモリは使用中ですが、プロセスのメモリ過負荷のためにスワップアウトした後に使用されなくなったメモリです。多くのプロセスには起動時にのみ使用されるメモリがあるため、これは実際には良いことです。交換すると、プロセスとバッファ/キャッシュ用の空きRAMが増えます。
その理由は以前の場合したOOM が発生し、イベントが発生した直後にすべてのスワップ領域が再び解放されます。これはおそらく、OOMを発生させたプロセスがすべてのスペースを使用し、停止後にすべてのスワップスペースが再び解放されたためです。
OOMが発生する唯一の時間は、使用可能なスワップスペースがなく、使用可能なRAMがない場合です(コマンドの「使用可能」列であるバッファ/キャッシュを考慮free
)。
残りのケースでは、通常、Linuxのメモリ管理が正しい操作を実行すると信頼できます。実行中のロード/アプリケーションの種類によって特別な要件がある場合にのみ、メモリ管理の調整を開始できます。