バグが原因でプロセスが多数のスレッドを生成し、メモリを消費して、スワップ パーティションへの大量のスワップが発生するという問題がありました。そこで、バグのあるプログラムを早期に失敗させるため、スワップをオフにしました (サーバー クラスターでは推奨されています)。驚いたことに、これではまったく状況は改善されませんでした。同様に、vm.swappiness0 に設定しても効果はありませんでした。 iotop 0読むディスクから（書き込みはほとんどなし）。
Linux カーネルは依然としてメモリ内のコード ページをスワップしており、必要に応じて上書きされたコード ページをディスクから再読み込みしているのではないかと思います。RAM が非常に少ない場合、これが頻繁に発生し、スラッシングが発生して、コンピューターがほとんど応答しなくなります。
この不幸で潜在的に危険な状況を防ぐにはどうしたらよいでしょうか。スワップをオフにし、そのプロセスのメモリと CPU の制約のために cgroup をオフにし、最大 30 プロセスに対して ulimit を設定してみました。状況は改善されませんでした。(まあ、これは完全に正しいわけではありません。数百 MB を永久に未使用のままにする RAM 制限は役立ちました。)
特に、メモリ内のコード セグメントのスワップを防ぎ、RAM を要求するプロセスが次の malloc で単に NULL を取得できるようにすることはできますか?
答え1
メモリオーバーコミットアカウンティングを調整し、デフォルトのオプション0（ヒューリスティックオーバーコミット）ではなくオプション2（オーバーコミットしない）に設定するのはどうでしょうか？その説明には次のように書かれています。
Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable amount (default is 50%) of physical RAM.
Depending on the amount you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
上記の抜粋はカーネルドキュメント
ポリシーはvm.overcommit調整可能に設定できます。