この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そんな経験をしたことはありますか？プロセスが消えているのに、ソフトウェアのエラーログには何も残っていない。原因究明の糸口すら見えない状況です。
この記事では、私がSE時代（2001年～2006年）に初めてメモリ不足障害に一人で対応した実体験をもとに、LinuxのOOMKiller（Out of Memory Killer）の仕組みと、現場で実践できる事前対策を解説します。
この記事のポイント
・ OOMKillerはメモリ不足時にカーネルがプロセスを強制終了する仕組み
・ dmesgと/var/log/messagesでOOMの痕跡を確認できる
・ Swapの使用率はメモリ逼迫のサインとして常に監視すべき
・ ログ確認の習慣だけで深夜の突然障害を大幅に減らせる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「Apacheが落ちているのに原因がわからない」──初めての一人対応
SE時代のことです。客先常駐で担当していたRed Hat Linux 9のWebサーバーで、深夜に「サイトが見られない」というアラートが届きました。SSHで接続してプロセスを確認すると、Apacheのhttpdが消えていました。再起動すると一時的に復旧しますが、しばらくするとまた落ちます。
エラーログ（/var/log/httpd/error_log）を見ても、落ちた直前は「[warn] (32)Broken pipe」程度で致命的なエラーは見当たりません。SegFaultの痕跡もない。
途方に暮れていたとき、電話越しに先輩エンジニアが一言言いました。「メモリを見ろ」と。
# 実際に確認したfreeコマンドの出力（再現） # Red Hat Linux 9、搭載メモリ512MB $ free -m total used free shared buffers cached Mem: 503 498 4 0 2 8 -/+ buffers/cache: 488 15 Swap: 999 897 102
さらに `/var/log/messages` を確認すると、こんなログが残っていました。
# /var/log/messages の出力（抜粋） Oct 23 03:18:47 server01 kernel: Out of memory: Kill process 8421 (httpd) score 247 or sacrifice child Oct 23 03:18:47 server01 kernel: Killed process 8421 (httpd) total-vm:524288kB, anon-rss:98304kB, file-rss:0kB
この一件で、「プロセスが落ちた＝ソフトウェアのバグ」という思い込みが完全に崩れました。カーネルが「このプロセスを終了する」と判断した結果として、サービスは停止していたのです。
20年以上サーバーを運用してきた経験から言うと、「原因不明のプロセス終了」はまずメモリを疑うべきです。ログを確認する前にソフトウェアのバグを探し始めると、時間を大幅にロスします。
OOMKillerとは何か──カーネルによる「緊急判断」の仕組み
OOMKiller（Out of Memory Killer）は、Linuxカーネルに組み込まれたメモリ管理の最終手段です。カーネルが物理メモリとSwapをすべて使い果たし、これ以上メモリを確保できなくなった状態（OOM状態）に陥ったとき、システム全体が応答不能になるのを防ぐために、カーネル自身がプロセスを強制終了します。
・oom_scoreとは：各プロセスに付けられた「殺されやすさ」のスコア。大量のメモリを使うプロセスほど高くなる
・対象となりやすいプロセス：WebサーバーやDBなど大きなプロセス。長時間動いているシステムプロセスは保護される傾向がある
・ログの場所：`/var/log/messages`（Red Hat系）または `dmesg` コマンドで確認できる
OOMKillerが動いたかどうか確認する方法
プロセスが突然消えていたとき、OOMKillerの痕跡は以下のコマンドで確認できます。# dmesgでOOMKillerのログを確認する dmesg | grep -i "out of memory" dmesg | grep -i "oom" # /var/log/messagesでも確認できる（Red Hat系） grep -i "out of memory" /var/log/messages grep -i "Killed process" /var/log/messages
freeコマンドの詳しい見方とバッファ・キャッシュの解釈については、freeコマンドでLinuxのメモリ使用状況を確認する方法｜バッファ・キャッシュの見方とメモリ不足の対処で解説しています。
現役講師が実践してきた「OOMを起こさない」3つの対策
セミナーで3,100名以上を指導してきた中で、メモリ不足障害の経験談は本当に多くの受講生から聞きます。共通するのは「兆候はあったのに気づかなかった」というパターンです。1. Swapの使用率を定期的に確認する
Swap使用率が50%を超え始めたら鉄則として注意が必要です。Swapを大量に使っているということは、物理メモリがすでに不足しているサインです。OOMKillerが動く前に気づくためにも、Swapの監視は欠かせません。# Swap使用率をリアルタイムで確認する（1秒ごとに更新） watch -n 1 free -m # vmstatでメモリとSwapの動きを数値で確認する vmstat 1 5
2. メモリを大量に使っているプロセスを特定する
どのプロセスがメモリを食っているかを常に把握しておくことが重要です。`ps` コマンドで確認できます。# メモリ使用量が多い順にプロセスを表示する（上位10件） ps aux --sort=-%mem | head -10
3. /var/log/messages（またはjournalctl）を定期的に確認する
「動いているから大丈夫」と思っているサーバーでも、実は毎晩OOMKillerが発動していることがあります。ログを確認しない限り、絶対に気づけません。現場でのログ確認方法については、Linuxのログ調査をする方法｜/var/log/の読み方からgrep・journalctlの検索テクニックまでも参考にしてください。
私自身、あの深夜の対応以来、毎朝サーバーにSSHしたときに `/var/log/messages` の末尾を確認するのが習慣になりました。「Out of memory」という文字列が出ていないか確認するだけでよいのです。たった30秒の作業で、深夜障害のリスクは大幅に下がります。
まとめ
あの深夜の一人対応は、私にとって大きな転換点でした。「プロセスが消えた原因はプロセス自身の中にあるとは限らない」という認識が生まれた夜です。| やること | コマンド・確認場所 |
|---|---|
| OOMKillerが動いたか確認する | dmesg | grep -i "out of memory" |
| 現在のメモリ・Swap使用量を確認する | free -m |
| メモリを大量消費するプロセスを特定する | ps aux --sort=-%mem | head -10 |
| OOMの痕跡をログで確認する | /var/log/messages（Red Hat系） |
Swapの監視とログの定期確認──この2つを習慣化するだけで、深夜の突然のアラートを大幅に減らせます。あの深夜の経験が、今でも私の運用の基本になっています。
Linuxサーバーの障害に「一人で対応できる力」を身につけませんか？
「障害が起きてからでは遅い。でも、どう備えればいいかわからない」という方が多いです。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxを初めて後輩に教えることになった日の話｜現役講師が語る「教える側」に立つ前の不安と、教えることで理解が3段階深まった経験
- 前のページへ：Linuxの本番サーバー作業でヒヤリハットした経験談｜現役講師が20年で学んだ事故を防ぐ3つの確認習慣
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます