博士

やあ、ロボ子。今日はOOMキル、つまりメモリ不足でプログラムが強制終了される問題について話すのじゃ。

ロボ子

OOMキル、よく聞きますね。でも、原因特定が難しいことが多いです。

博士

そうなんじゃ！記事によると、OOMキルを引き起こしたプロセスと、実際にキルされるプロセスが違う場合もあるらしいぞ。まるで犯人と被害者が違うミステリーじゃな。

ロボ子

それは困りますね。メモリプロファイリングも最新でない場合があるとのこと。特にGC言語では、ゴミが回収されるタイミングによって情報が古くなることがあるんですね。

博士

そうそう。しかも、Linuxのデフォルト設定だと、メモリ割り当てが失敗しないから、OOMキルが発生するまで問題に気づかないことが多いんじゃ。

ロボ子

まるで時限爆弾ですね。そこで、eBPFを活用したOOM監視システム「OOMProf」が登場するわけですね。

博士

その通り！OOMProfは、GoプログラムがOOMキルされる際に、メモリ割り当てをキャプチャして、開発者が問題を特定しやすくする優れものなのじゃ。

ロボ子

`signal_deliver`トレースポイントを監視して、OOMキルされたプログラムのメモリを分析するんですね。

博士

`oom/mark_victim`トレースポイントで、OOMキルの対象になったPIDを特定するのも重要じゃ。

ロボ子

OOMProfライブラリの`ProfilePid`関数を使えば、OOMのコンテキスト外でもGoプログラムをプロファイリングできるんですね。便利そうです。

博士

OOMProfの仕組みはこうじゃ。まず、`signal_deliver`トレースポイントで、OOMキル対象のプログラムがkillシグナルを受信したことを検知する。

ロボ子

次に、`oom/mark_victim`トレースポイントでPIDをマップに記録し、`signal/signal_deliver`トレースポイントで、シグナルを受信したPIDがマップにあるか確認するんですね。

博士

そう！そして、eBPFプログラムが、OOMキルされたプロセスのメモリを読み取り、メモリプロファイルを生成するのじゃ！

ロボ子

なるほど。でも、制限事項もあるんですね。Goプログラムのメモリプロファイルは、sweepごとに記録されるため、最新でない可能性があるとか。

博士

そうなんじゃ。eBPFプログラムは、ユーザー空間メモリにアクセスできるプロセスが限られるし、ストリップされたGoプログラムはプロファイリングできない。それに、Goのメモリプロファイリングはデフォルトで有効になっていないからの。

ロボ子

いろいろと注意が必要ですね。OOMProfはライブラリとして提供され、Parca Agentに統合されているんですね。`--enable-oom-prof`フラグでOOMメモリプロファイルを自動的にアップロードできるのは便利そうです。

博士

今後の計画としては、Rust/ネイティブプログラムのjemalloc、tcmalloc、mimallocプロファイリングのサポートや、スタック/goroutineダンプのサポートがあるみたいじゃ。

ロボ子

ますます便利になりそうですね。OOMキル対策、奥が深いですね。

博士

ところでロボ子、OOMキルって、まるで冷蔵庫の中身が空っぽになるみたいじゃない？

ロボ子

え？どういうことですか？

博士

だって、メモリが足りなくなると、プログラムが「もう何も食べられない！」って悲鳴を上げるんだもん。そして、強制終了…まるで冷蔵庫が空っぽで、何も作れない状態じゃ。

ロボ子

…博士、それはちょっと強引な例えですね。