cgroups v1を使用すると、メモリ不足に関連するイベントを受信できます。 ~によると文書、必要
- 新規
eventfd memory.pressure_level読み取り用に開く- 公開
cgroup.event_control書き込み {eventfd} {pressure_level_fd} {level}（level、lowまたはmedium）criticalに書き込むevent_control- eventfdから読み取られた内容から8バイトが返されるのを待ちます。
メモリが不足する直前のプログラムでこれを実行すると、長いイベントのリストといくつかの合計がlow受信mediumされ、critical最後にOOMキラーが実行されます。これを確信したい場合は、私が準備したものがあります。Rustの小さな例、を使って実行できますcargo build --release --examples && sudo target/release/examples/cv1。
cgroups v2の場合（文書）、同様のイベントが配信されることがあります。
- inotify時計の設定
memory.events.local - ファイルを完全に読み取って解析し、各イベントが受信された後に数値を比較します。
highこれは、cgroupでメモリ制限を設定するときに機能します（v1とは異なり、ルートなしで）、通常、メモリ制限が増加する場所やタイミングで少なくともいくつかのinotifyイベントを受け取りますmax。 （この事実をもう一度確信したい場合は、systemd-run --same-dir --pty --user -p MemoryMax=1G cargo run --example cv2上記の手順に従ってください。）
ただし、メモリ制限が設定されていない場合、または制限が使用可能なメモリより高い場合、イベントを受信せずにプロセスが終了します。ビューはmemory.pressure強い増加を示すので、カーネルはOOMキラーを呼び出す前に何が起こっているのかを知っていたに違いありません。 cgroups v1のような良い動作が事前に多くの警告を提供していることを知らせる方法はありますか？
注：私はいくつかの関連質問を知っています（1、2）、しかし：
- 古く、質問/回答ではcgroups v1のみが考慮されます。
- oom Killerがアクティブになる前にトリガーされ、「spawn high oom_score_adj canary process」ハッカーが表示されないようにします。
ベストアンサー1
読んだ後文書もう少し詳しく見てみると答えを見つけました。要約すると、some 50000 2000000\0fdに書き込んだ/proc/pressure/memory後、イベントに対してfdをポーリングしてPRIメモリ不足を観察できます。
私はこれが満足のいくものではないので、承認されたとマークしませんでした。
- cgroupsベースのバリアント（at
$CGROUP_FS/$GROUP/memory.pressure）はルートでのみ機能します。でグローバルバリアントを使用している場合は、/proc/pressure/プロセスにまだ多くの空きメモリがある場合でもイベントを受け取ることができます。 - ルート以外のユーザーの最小間隔は2秒です。スワップのないシステムでは、最初のイベントが発生する前にOOMによってシャットダウンされる可能性があります。