そんな経験をしたことはありますか？プロセスが消えているのに、ソフトウェアのエラーログには何も残っていない。「とりあえず再起動したら直ったからいいか」と済ませてしまうと、同じ障害が繰り返されます。
この記事では、私がSE時代（2001年～2006年）に初めてメモリ不足障害に一人で対応した実体験をもとに、LinuxのOOMKiller（Out of Memory Killer）の仕組みと、カーネルログでの確認方法・現場で実践できる事前対策を解説します。「ログを見ても分からない」のではなく、「正しいログを見ていなかった」だけ──この気づきが、サーバー管理の大きな転換点になります。
この記事のポイント
・ OOMKillerはメモリ枯渇時にカーネルがプロセスを強制終了する仕組み
・ dmesg -T や journalctl -k でOOMの痕跡を確認できる
・ Swapの使用率とAvailableメモリがOOM接近の早期サインになる
・ ログ確認の習慣だけで深夜の突然障害を大幅に減らせる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「Apacheが落ちているのに原因がわからない」──初めての一人対応
SE時代のことです。客先常駐で担当していたRed Hat Linux 9のWebサーバーで、深夜に「サイトが見られない」というアラートが届きました。SSHで接続してプロセスを確認すると、Apacheのhttpdが消えていました。再起動すると一時的に復旧しますが、しばらくするとまた落ちます。
エラーログ（/var/log/httpd/error_log）を見ても、落ちた直前は「[warn] (32)Broken pipe」程度で致命的なエラーは見当たりません。SegFaultの痕跡もない。「Apacheのログには何も残っていないのに、なぜプロセスが消えるのか」──そんな状態が続いていました。
途方に暮れていたとき、電話越しに先輩エンジニアが一言言いました。「メモリを見ろ」と。
# 実際に確認した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
この一件で、「プロセスが消えた原因はプロセス自身の中にあるとは限らない」という認識が生まれました。Apacheのエラーログに何も残っていなかった理由は、Apacheが「殺された側」だったからです。プロセスが強制終了される場合、自分でログを書く暇がありません。証拠は、Apacheのログではなくカーネルログに残っていたのです。
20年以上サーバーを運用してきた経験から言うと、「原因不明のプロセス終了」はまずメモリを疑うべきです。ログを確認する前にソフトウェアのバグを探し始めると、時間を大幅にロスします。Apacheのログを探す前に、カーネルログ（`dmesg` や `/var/log/messages`）を確認する習慣が、深夜障害の解決時間を大幅に短縮します。
OOMKillerとは何か──カーネルによる「緊急判断」の仕組み
OOMKiller（Out of Memory Killer）は、Linuxカーネルに組み込まれたメモリ管理の最終手段です。カーネルが物理メモリとSwapをすべて使い果たし、これ以上メモリを確保できなくなった状態（OOM状態）に陥ったとき、システム全体が応答不能になるのを防ぐために、カーネル自身がプロセスを強制終了します。
・oom_scoreとは：各プロセスに付けられた「殺されやすさ」のスコア。大量のメモリを使うプロセスほど高くなる
・oom_score_adjとは：管理者がoom_scoreを補正するための値（-1000～1000）。-1000に設定するとOOMKillerの対象外になる
・対象となりやすいプロセス：WebサーバーやDBなど大きなプロセス。長時間動いているシステムプロセスは保護される傾向がある
・ログの場所：`/var/log/messages`（Red Hat系）または `dmesg` / `journalctl -k` コマンドで確認できる
OOMKillerが動いたかどうか確認する方法
プロセスが突然消えていたとき、OOMKillerの痕跡は以下のコマンドで確認できます。# dmesgでOOMKillerのログを確認する（-Tオプションで人間が読みやすい時刻表示） dmesg -T | grep -i "out of memory" dmesg -T | grep -i "oom" # /var/log/messagesでも確認できる（Red Hat系） grep -i "out of memory" /var/log/messages grep -i "Killed process" /var/log/messages # journalctlでカーネルログを確認する（再起動後でも過去のログを参照できる） journalctl -k | grep -i "oom" journalctl -k --since "2026-09-06 02:00" | grep -i "oom" # 特定プロセスのOOMスコアを確認する（PIDを指定） cat /proc/12345/oom_score
受講生からよく聞かれる質問が「dmesgとjournalctlの使い分けが分からない」というものです。簡単に言うと、`dmesg` は再起動すると内容がリセットされますが、`journalctl -k` はsystemdが永続化して保存しているため、再起動後でも過去のログを確認できます。障害調査では `journalctl -k` の方が確実です。`-T` オプションを付けると人間が読みやすい時刻表示になるのでおすすめです。
freeコマンドの詳しい見方とバッファ・キャッシュの解釈については、freeコマンドでLinuxのメモリ使用状況を確認する方法｜バッファ・キャッシュの見方とメモリ不足の対処で解説しています。
現役講師が実践してきた「OOMを起こさない」3つの対策
セミナーで3,100名以上を指導してきた中で、メモリ不足障害の経験談は本当に多くの受講生から聞きます。共通するのは「兆候はあったのに気づかなかった」というパターンです。OOMKillerが発動してから調べるより、発動する前に気づく方が圧倒的にダメージが少なくて済みます。1. Swapの使用率と空きメモリを定期的に確認する
Swap使用率が50%を超え始めたら注意が必要です。Swapを大量に使っているということは、物理メモリがすでに不足しているサインです。OOMKillerが動く前に気づくためにも、Swapの監視は欠かせません。# Swap使用率をリアルタイムで確認する（1秒ごとに更新） watch -n 1 free -m # vmstatでメモリとSwapの動きを数値で確認する vmstat 1 5 # /proc/meminfoでAvailableメモリとSwapの詳細を確認する cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree"
2. メモリを大量に使っているプロセスを特定する
どのプロセスがメモリを食っているかを常に把握しておくことが重要です。`ps` コマンドや `top` コマンドで確認できます。# メモリ使用量が多い順にプロセスを表示する（上位10件） ps aux --sort=-%mem | head -10 # topコマンドでリアルタイム確認（起動後Mキーでメモリ順ソート） top # Apacheのプロセス数を確認する ps aux | grep httpd | grep -v grep | wc -l
私が現場でよく見かけるのが、Apacheの `MaxRequestWorkers`（旧 `MaxClients`）の値をサーバーのメモリ容量に合わせず初期値のまま運用しているケースです。1ワーカープロセスあたり30～50MBのメモリを消費するため、メモリが1GBのサーバーで `MaxRequestWorkers` を150のままにしておくとあっという間にメモリが枯渇します。月に一度、Apacheのプロセス数を確認して設定値に近づいていないか照合する習慣をつけてください。
3. /var/log/messages（またはjournalctl）を定期的に確認する
「動いているから大丈夫」と思っているサーバーでも、実は毎晩OOMKillerが発動していることがあります。ログを確認しない限り、絶対に気づけません。現場でのログ確認方法については、Linuxのログ調査をする方法｜/var/log/の読み方からgrep・journalctlの検索テクニックまでも参考にしてください。
私自身、あの深夜の対応以来、毎朝サーバーにSSHしたときに `/var/log/messages`（または `journalctl -k`）の末尾を確認するのが習慣になりました。「Out of memory」という文字列が出ていないか確認するだけでよいのです。たった30秒の作業で、深夜障害のリスクは大幅に下がります。
さらに一歩進めるなら、cronで以下のコマンドを定期実行してメールに転送する仕組みも有効です。毎朝メールを確認するだけで、前夜のカーネルメッセージを能動的に把握できます。
# 毎朝6時にOOM関連のカーネルログをメールに送信するcronの例 # crontab -e で追記する 0 6 * * * journalctl -k --since "yesterday" | grep -iE "oom|out of memory|killed process" | mail -s "OOMチェック $(hostname)" your@email.com
まとめ
あの深夜の一人対応は、私にとって大きな転換点でした。「プロセスが消えた原因はプロセス自身の中にあるとは限らない」という認識が生まれた夜です。Apacheのエラーログに何も残っていなかったのは、Apacheが「殺された側」だったから。証拠は常にカーネルログにありました。| やること | コマンド・確認場所 |
|---|---|
| OOMKillerが動いたか確認する | dmesg -T | grep -i "out of memory" |
| 再起動後も過去のOOMを確認する | journalctl -k | grep -i "oom" |
| 現在のメモリ・Swap使用量を確認する | free -m |
| Availableメモリの詳細を確認する | cat /proc/meminfo | grep -E "MemAvailable|SwapFree" |
| メモリを大量消費するプロセスを特定する | ps aux --sort=-%mem | head -10 |
| OOMの痕跡をログで確認する | /var/log/messages（Red Hat系） |
Swapの監視とカーネルログの定期確認──この2つを習慣化するだけで、深夜の突然のアラートを大幅に減らせます。あの深夜の経験が、今でも私の運用の基本になっています。
Linuxサーバーの障害に「一人で対応できる力」を身につけませんか？
「障害が起きてからでは遅い。でも、どう備えればいいかわからない」という方が多いです。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
＜PR＞手元に置いて学びを深める1冊
まず無料メルマガでOOM対策の基礎を学ぶのが第一歩、加えてカーネル内部のメモリ管理やI/Oの仕組みを体系的に手元で深めるなら本書。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 次のページへ：Linuxを初めて後輩に教えることになった日の話｜現役講師が語る「教える側」に立つ前の不安と、教えることで理解が3段階深まった経験
- 前のページへ：Linuxの本番サーバー作業でヒヤリハットした経験談｜現役講師が20年で学んだ事故を防ぐ3つの確認習慣
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます