私はLinux 5.15とUbuntu 22.04を使用しています。
多くのメモリを使用するプロセスがあります。私のコンピュータのRAMよりも多くのメモリが必要です。初めて実行したときにOOM Killerによって終了しました。私が理解したのは、システムにメモリが不足し、OOM Killerが実行されてプロセスが終了することです。これは意味があります。私もこれが起こったことだと確信しています。見てみると、dmesgすべてがそこにありました。
だから、スワップスペースを追加しました。プロセスの実行に時間がかかってもかまいません。頻繁に実行しません。
プロセスを再実行します。今回のランは最初のランより長かった。システム全体が非常に遅れており、これはシステムが大量の交換を実行したときに発生します。効果があるようだったら…それから死んでしまいました。プロセスが終了するだけでなく、親シェルプロセス、親Tmuxプロセス、Tmuxプロセスの親シェルプロセス、さらにはGNOME端末プロセスも終了します。それ親！しかし、殺人プロセスは中止されます。もはや両親は死なない。
当初は、利用可能なスワップスペースがまだまだあるにもかかわらず、OOM Killerが再実行されたと考えて、GNOME端末プロセスを終了することにしました。ところで確認してみるとdmesg新しいjournalctl -kものはありませんでした。 OOM Killerが実行されたという指示はありません。
最初の質問：カーネルリングバッファに何も書き込むことなくOOM Killerを実行できる状況はありますか？
私を混乱させるのは、Linuxカーネルがスワッピングを開始するようですが、なんとか十分にスワップしないか、十分に速くスワップしないということです...など。
だから私はそれを増やしましたvm.swappiness。これは実際にシステムの安定性に影響を与えてはいけません。これはパフォーマンスを最適化するためのノブです。カーネルvm.swappinessに設定されていても、0その領域の利用可能なメモリがしきい値しきい値を下回ると、カーネルはまだスワップを開始する必要があります。
ところでスワップが始まるようでしたが不足ですね… だからもう少しスワップしてみるようにvm.swappiness勧誘しようと付け加えました。100
その後、プロセスを再実行します。システム全体は非常に遅れます。これは、プロセスが正常に完了するまで多くの交換を実行したときにシステムが実行する操作です。
2番目の質問：利用可能なメモリが重要なしきい値を下回っていて、利用可能なスワップ領域が確実に十分ですが、カーネルが利用可能なスワップ領域を使用しないのはなぜですか？変更はなぜvm.swappiness変更をもたらすか。
修正する:
追加テストでは、この設定がvm.swappiness信頼できるソリューションではないことがわかりました。に設定してもvm.swappinessいくつかの失敗が発生しました100。それ可能プロセスが正常に完了する可能性が高くなりますが、わかりません。
答え1
利用可能なスワップスペースが完全に使用される前にOOMイベントが発生する可能性がある理由はいくつかあります。OOMイベントがOOMキラースレッドをトリガーしたり、より悪いシグナルを引き起こす可能性があります。
A/一般的なメモリ割り当てとOOMイベント情報
カーネル開発者は多くのプログラムを知っているのでmalloc()記憶に残る」もしかして」とあまり使用しないでください。少なくとも、システム上で実行されているすべてのプロセスは、同時に要求されたメモリを必要としないと静的に期待し、カーネルは実際にmalloc（または友達）でメモリを予約しません。 ）
の代わりに、実際のマッピングが発生するためにメモリへのA書き込みアクセス（必然的にページエラーが発生する）を待ちます。
この時点でメモリがすぐに利用できない場合、カーネルはより良い日を待ちます（1）より良い日が早く来ない場合、OOMイベントに応じてOOMイベントがトリガーされます。一部のsysctl設定（panic_on_oom）、OOM-killerを実行するか、カーネルパニックを発生させます。
B/スワップ領域の空き領域がどれだけ多くてもOOMイベントが発生するのはなぜですか？(2)
- B.1/スワッププロセスがスペースを確保するのに十分速くないため：
§Aに示すように、カーネルは一部のメモリが利用可能になるまで待ちません。したがって、実行中のプロセスがないと、一部のメモリが解放されます。そしてファイルシステムのキャッシュは最小限に抑えられているので、交換することがメモリページを取得する唯一の方法です。これは猶予期間に合わない。 Gigメモリを交換できますが、OOMイベントが発生します。
ディスクへのランダムアクセスは遅く、スワップスペースは実行中のプロセスで使用されるファイルシステムと同じディスク上にある可能性があるため、スワップ領域へのアクセスははるかに遅くなります。
それでもシステムがこのような状況に陥らないようにする方法があります。覚えるアキレスとカメ: できるだけ早く交換を開始してください。システムに物理メモリが必要なくなったら、ページの移動を開始します。
これはまさにあなたが実際に間接(3)増えたら手に入れよう交換性。ただし、これは設定の副作用にすぎません。「最高」設定は標準偏差が高く、ワークロードに大きく依存します。ベンチマークが必要です。 (4)(5) - B.2：システムは交換可能なすべてを交換したので
プロセス使用量mlock()設計上、交換不可能が保証されたすべてのページを取得するためにシステムコールが実行されます。もっと悪い？mlockall()（6）
これにより、相当数のMBがスワップ不可能になります。
巨大なTLBページまた、メモリ不足のため交換できない場合は、cat /proc/meminfoその目的のために予約されたメモリ量が報告されます。
C/メモリ不足が高いとスレッドが終了する可能性があるが、OOM-killerは何も記録しない理由。 (7)
- C.1：アプリケーション固有の設計
超過割り当ての決定は、mallocリリース時にカーネルによって行われます。しかし、カーネルのデフォルト値は「楽観的戦略」、カーネルは予約要求を拒否し、malloc()呼び出しスレッドにNULLポインタを返します。これは常に発生する可能性があります。
この場合、呼び出しプロセスがこの例外をどのように処理するかに応じて、要求を更新するのに適した時間を待つか、正常に中断するか、無視してsegfaultを実行して終了するか、上位層の連続現象が発生します。早期に終了し、OOM-killerの介入なしにかなりの量のメモリが確保されます。 （そして再びスワップに残っているスペースに関係なく） - C.2/ 一部のスレッドが不快な信号を捉えたため システムは大きなページの余分な割り当ても許可する可能性があるため、ページが欠落しているときに大きなページがない場合、ミッションはSIGBUSに送られ、しばしば残念ながら死にます。。
1:ええとより良いミリ秒実際には最大6回まで確認するので、その間に数ナノ秒ほど待機します。この数は現在古いカーネルの私の記憶に属し、それ以降に変更された可能性があります。
2:厳密に言えば、Linuxはそうではありません。交換~から交換プロセスアドレス空間全体をディスクに転送することを意味します。 Linuxは実際に実装ページング実際には単一ページを送信するからです。しかし、文書と議論では交換…それではそうします。
サム： 「間接的に」スワッピングを早く開始するのはこの設定の副作用に過ぎないため、主にファイルシステムのキャッシュとプロセスページの好みを知らせるためのものです。
ファイルシステムの高いIOオーバーヘッドにより、Linuxはキャッシュに最大限の物理メモリを使用します。
swappiness値が高いほど、システムはプロセスの開始時にプロセスページをより積極的に交換し、メモリ不足のために迅速に回収できるキャッシュページの数が増えます。
4:ところで、これはまたあなたの質問の反対側を説明します。利用可能な空きRAMが多い場合、なぜシステムを交換するのですか?
5:主な組織（RHEL、ORACLE ...）が交換性を厳密な最小値に設定することをお勧めしますが...に設定することを強くお勧めします。 。
技術の可用性として、例えば交換、ファイルシステムIOよりもスワッピングをより安くすることができるので、100より大きいスワッピング値は不可能ではありません。
6:
mlockall() locks all pages mapped into the address space of the calling process. This includes the pages of the code, data, and stack segment, as well as shared libraries, user space kernel data, shared memory, and memory-mapped files. All mapped pages are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked.
7:有効になっていても、OOMキラーはやや怠惰で面倒な作業を自分で終了させることを好むことに注意してください。だから犯人のシグナルが待っているなら... OOMキラーは彼らが措置を取るのを待っているでしょう...もしかして...
答え2
まずありがとうございます。MC68020時間をかけてこの問題を調査していただきありがとうございます。偶然にも、彼らの答えは、この場合、実際に何が起こっているのかを扱いません。しかし、彼らは良い答えであり、将来の有用な参考資料であるため、とにかく賞金を受け取りました。
私に感謝したいです。フィリップ・クーリン彼の答えは完全に正確ではなかったが、私に正しい方向を示した。
問題は次のとおりです。システム管理ツール。
問題と回避策は次のとおりです。Ubuntu 22.04でシステムOOMプロセスキラーを無効にする方法は？
簡単に言うと：
systemctl disable --now systemd-oomd
systemctl mask systemd-oomd
システムサービスが警告なしにプロセスツリー全体をシャットダウンしなくても、毎回プロセスが完了するまで確実に実行できるようになりました。
答え3
OOMキラーがプロセスを終了させる原因が何であるかはわかりませんが、その事実は文書化されていません。極端な場合、OOM Killerはカーネルログをディスクに書き込むプロセスを停止する可能性があります。あなたの説明によるとそうではありません。
あなたの説明から2つの重要な関連情報を抽出します。
- OOM-Killerログがありません
- 実際、全体のプロセスツリーは次のように構成されます。GUIウィンドウ消えた。
これは少し推測ですが、GUI自体がそれを殺すように聞こえます。
それはおそらくクラッシュしたように見えるように作られたバンプだったでしょう。たとえば、頻繁な不安が原因でブラウザがクラッシュするケースを見たことがあります。衝突検出器は活動を確認できず、プログラム自体に問題があると仮定し、プログラムがカーネルの応答を待っているだけであることを理解していません。
頑張りますコンソール切り替えGUIなしでコマンドラインから実行してください。これは少なくともGNOME自体の干渉を排除します。