私はすべての種類の自動OOMキラーを非常に嫌い、これらの状況を手動で解決することを好む。だから私は長い間
vm.overcommit_memory=1
vm.overcommit_ratio=200
ただし、これにより、メモリがオーバーフローするとシステムが応答しなくなります。 HDDと6GBのRAMを搭載した従来のノートブックでは、テキストVTに切り替え、いくつかのコマンドを実行して実行されるまで数分待たなければならないことがありました。そのため、このような状況を事前に気付くことができる成果指標が多く、それがなぜ必要なのか質問をよく受ける方だ。そして常に役に立つわけではありません。ノートブックを使用しないときにメモリオーバーフローが発生すると、遅すぎるためです。
SSDと12GBのRAMを備えた最新のノートパソコンでは、より良いと思いましたが、実際には悪いです。最大16.4 GBの圧縮スワップスペースを可能にするzRamがあり、ほとんど使い果たされるvm.swappiness=200と、システムが従来のラップトップよりも応答しなくなり、VTスイッチもほとんど機能せず、ローカルからシステムにSSH接続できません。したがって、私の唯一の手段は、Alt + SysRq + RFを使用してカーネルの手動OOMを盲目的に呼び出すことです。時には重要なプロセスを終了することを選択します。たとえば、dbus-daemonスワップがほぼいっぱいになったときにサウンドアラートを持つデーモンを作成することもできますが、これは再び発生しました。部分的には臨時方便で、とにかく時間内にそこに到着できないようでしたからです。
過去にはthrash-protect。貪欲なプロセスに転送SIGSTOPし、自動的にSIGCONT-sを実行してロック全体を延期し、問題を手動で解決するのに多くのことができますが、深刻な過負荷の状況ではほとんどすべてが凍結し始めます（許可リストとして明示的にリストされる）することができます）。そしてそれは多くの刺激的な副作用を持っています。たとえば、シェルが固定されている場合、その子プロセスは、シェルが固定解除された後でも固定されたままになる可能性があります。両方のプロセスがメッセージバスを共有し、プロセスの1つが停止すると、メッセージが急速にバスに蓄積され、RAM使用量が急激に増加または停止する可能性があります（グラフィックサーバーとマルチプロセスブラウザは特にこの現象が発生しやすい）。 。
sshd提案したように-20優先順位で実行してみました。エマルジョンしかし、実際には役に立ちません。デフォルトの優先順位ほど応答しません。
私はいつもRAMにロックされていて、システムの残りの部分がどんなに過負荷になっても使用できる緊急コンソールが欲しいです。 Windows NT≥6のCtrl + Alt + Del画面に似ており、はるかに優れています。一部のRAMがパラメータを使用して予約できることcrashkernelを考えると、kdumpこのメカニズムや他のカーネルメカニズムを活用してタスクを実行できると思いますか？
ベストアンサー1
ユースケースでは、mlockallシステムコールを使用して特定のプロセスが絶対にスワップされないようにして、スワップスラッシングの速度低下を防ぎます。
earlyoomこのハッキングのカスタムルールをお勧めします。