落ちたはずのプロセスがログに理由を残さず消えていたことに気づき、サーバーのメモリの状態を落ち着いて調べはじめた一人運用の保守担当者
障害対応・運用監視約12分

メモリ不足でプロセスが落ちる｜OOMの兆候の見つけ方と一次対処

夕方、監視の画面を何気なく見たら、いつも動いているはずのアプリのプロセスが消えていた。 アプリのログを見ても、エラーらしいエラーは残っていない。落ちる直前まで、いつも通りに処理をしていた形跡があるだけ。「なんで急に……」と、原因の入口すら見つからない——。

そんな経験、ありませんか。 プロセスが自分でエラーを吐いて止まったのではなく、メモリが足りなくなって、OS の側がプロセスを強制的に終了させていた、というケースがあります。これは OOM（Out Of Memory）と呼ばれる落ち方で、アプリのログには理由が残らないため、保守運用でいちばん追いにくいトラブルのひとつです。

この記事では、まず「本当に OOM だったのか」を確かめる手順、いまメモリが逼迫しているかを見る読み方、そして再発を止めるまでの一次対処を、一人運用の目線で順番に整理します。全部を一度に対処しようとしなくて大丈夫です。まずは「落ちた理由が OOM かどうか」を、はっきりさせるところから。

結論：プロセスが理由もなく消えていたら、①OOM だったか確かめる（dmesg や journalctl に「Out of memory: Killed process …」の記録がないか）②いまの逼迫を見る（free -h の available と、スワップの使用量）③一次対処（重い常駐を減らす・再起動で復旧・当面のスワップ確保）④再発を止める（メモリ使用の監視と、原因プロセスの上限設定）——の順で落ち着いて進めます。まずは①の「犯人が OOM かどうか」から。

コマンドは Linux を前提にしています。ディストリビューションやバージョンで出力やパスが少し異なります。ここを出発点に、本番へ反映する前に検証環境と公式情報で確認してください。

OOM とは何が起きているのか

Linux は、物理メモリ（RAM）が本当に足りなくなると、システム全体が固まってしまうのを避けるために、動いているプロセスのどれかを選んで強制終了します。この仕組みが OOM Killer（メモリ不足時にプロセスを“殺す”カーネルの機能）です。

ここでつらいのは、落とされたプロセスの側から見ると、自分の意思で止まったわけではないという点です。だからアプリのログには「メモリが足りませんでした」とは書かれず、処理の途中でぷつっと記録が途切れているだけになります。理由が本人のログに残らない——これが「原因不明で落ちた」ように見える正体です。

そして OOM Killer は、必ずしも「いちばんメモリを食っているプロセス」を選ぶとは限りません。カーネルは各プロセスに oom_score（殺されやすさの点数）をつけていて、その点数が高いものが優先的に落とされます。結果として、メモリを食っていた本当の原因ではなく、別の常駐プロセスがとばっちりで落ちることもあります。「なぜこれが？」という落ち方をするのは、このためです。

つまり大事なのは、「そのプロセスが悪かったか」ではなく「サーバー全体のメモリが足りなくなっていたか」を見ること。犯人探しの前に、まず現場全体の状況を確かめます。

OOM だったかを確かめる（まず犯人を特定）

プロセスが消えたとき、OOMだったかを確かめ、いまの逼迫を見て、一次対処へ進む流れを示した図
「落ちた理由の確認 → いまの逼迫の確認 → 一次対処」の順で進めると迷わない

プロセスが理由もなく消えていたら、まず OS 側の記録を見ます。OOM Killer が動いたときは、カーネルがその事実をログに残しています。

カーネルログ（dmesg）を見る

# 「out of memory」まわりだけ拾う（大文字小文字は無視）
dmesg -T | grep -i -E "out of memory|killed process|oom"

-T を付けると時刻が読みやすい形式で出ます。次のような行が見つかれば、OOM で間違いありません。

[Wed Jul  8 03:14:22 2026] Out of memory: Killed process 21575 (php-fpm) total-vm:...

Killed process 21575 (php-fpm) の部分で、いつ・どのプロセス（PID と名前）が落とされたかが分かります。

systemd の環境なら journalctl でも

# カーネルのログから OOM の記録を探す
journalctl -k | grep -i "out of memory"

# 期間で絞りたいとき（例：昨日の夜から今朝まで）
journalctl -k --since "2026-07-08 00:00" --until "2026-07-08 09:00"

ここで OOM の記録が見つからなければ、落ちた原因はメモリ不足ではなく、アプリ側のクラッシュや、別のプロセス（デプロイ・監視・cron）による停止を疑う方向へ切り替えます。犯人が違えば、打ち手も変わります。まず「OOM かどうか」を分けるのが、遠回りに見えていちばんの近道です。

いまの逼迫を見る（free とスワップの読み方）

OOM だと分かったら、次はいまこの瞬間、どれくらい余裕がないかを見ます。過去に一度落ちたのか、今もじわじわ逼迫し続けているのかで、対応の急ぎ方が変わります。

free -h

出力の例（-h は人が読みやすい単位で表示）：

              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.933Gi       120Mi        30Mi       300Mi       150Mi
Swap:          1.0Gi       0.98Gi        20Mi

見るべきは、次の2つです。

buff/cache（ファイルのキャッシュなど）は多くても心配いりません。ここは必要になれば OS が自動で空けてくれる領域で、available にはその分も見込まれています。「free が少ない＝危険」ではないのがつまずきやすいところです。見るのは available と Swap used。ここだけ押さえておけば大丈夫です。

何がメモリを食っているかを見る

逼迫していそうなら、使用量の多い順にプロセスを並べて、犯人の見当をつけます。

# メモリ使用率が高い順に上位10件（%MEM の降順）
ps aux --sort=-%rss | head -n 11

RSS（実際に使っている物理メモリ）の大きいプロセスが上に来ます。dmesg で落とされていたプロセス名と、ここで上位に来ているプロセスが一致するか、あるいは別物か——それが次の一次対処の入口になります。

一次対処：まず落ち着かせる

メモリ不足の一次対処として、重い常駐を減らす・再起動で復旧・当面のスワップ確保・上限設定の4つを並べた図
いったん落ち着かせてから、再発を止める設定へ。順番に一つずつで大丈夫

原因が「サーバー全体のメモリ不足」だと分かったら、まずはサービスを動く状態に戻します。急いでいるときほど、この順で。

  1. 落ちたサービスを復旧させる：落とされたプロセスを起動し直します（systemctl start <サービス名> など）。ただし、逼迫の原因を放置したまま上げ直すと、また同じところで落ちます。「なぜ足りなくなったか」の見当がついてから上げ直すのが安全です。
  2. 一時的にメモリを空ける：不要になっている常駐プロセスや、開発用に上げっぱなしのプロセスがあれば、いったん止めて available を回復させます。ps で上位に来ていた“身に覚えのない大食い”は、まずここで疑います。
  3. サーバーごと再起動して様子を見る（最終手段）：どうにも身動きが取れないときは再起動で一度リセットできますが、根本原因は消えていないので、再発監視とセットにします。「再起動で直った」で終わらせず、いつ・何が逼迫したかを記録に残しておきます。
  4. 当面しのぐスワップを足す：物理メモリの増設まで時間がかかる環境では、スワップ領域を一時的に足して急場をしのぐ選択もあります（swapon で追加）。ただしスワップは遅く、根本解決ではありません。あくまで「増設・改修までの延命」と割り切ります。

一次対処の目的は、原因の完全解決ではなく、まずサービスを落ち着かせて、腰を据えて調べられる状態を作ることです。ここまで来れば、いちばん怖い「鳴り続けている最中の対応」からは抜けられます。

影響：仕組みで気づけると、何が変わるか

放置すると、メモリ不足は「忘れたころに、また別のプロセスを巻き込んで落ちる」形で戻ってきます。しかも毎回ログに理由が残らないので、そのたびに原因調査を一からやり直すことになりがちです。逆に言えば、一度「見る場所」と「監視」を用意しておけば、同じ落ち方でうろたえることは、ぐっと減ります。

明日やること：まず「落ちた理由」を確かめる1手から

  1. 直近でプロセスが不審に消えたサーバーで、dmesg -T | grep -i "out of memory" を実行し、OOM の記録があるか確かめる。
  2. free -h を見て、available と Swap used の“いまの余裕”を把握する。逼迫していれば ps aux --sort=-%rss | head で大食いを特定する。
  3. いちばん止まると困るサーバーだけ、メモリ使用率（available が閾値を下回ったら通知）の監視を1本入れる。まずは1台でいい。
  4. 余力があれば、繰り返し犯人になるプロセスにメモリ上限を設定する（systemd サービスなら MemoryMax=、コンテナなら --memory など）。上限を超えたら、そのプロセスだけが止まるようにして、巻き添えを防ぐ。

この流れなら、30分で「落ちた理由の確認」と「いまの逼迫の把握」までは終わります。監視の1本は、次に同じことが起きたとき、あなたが気づく前にサーバーが教えてくれる備えになります。

メモリ不足・OOM 対応チェックリスト

最低ライン（優先順位つき：これだけで回る） 1) 原因を分ける：dmesg／journalctl -k で OOM の記録があるか確認する 2) 逼迫を見る：free -h の available と Swap used で今の余裕を把握する 3) 気づく仕組み：重要サーバーに「メモリ逼迫で通知」の監視を1本入れる

余力が出たら拡張

免除条件（省略可）

確認項目

よければ、こちらも

メモリ不足は、「サーバーのどこかが逼迫している」サインのひとつです。同じ“遅い・落ちる・詰まる”を切り分ける手順や、逼迫を前もって拾う監視の考え方も、あわせて型にしておくと落ち着けます。

メモリの逼迫を監視で拾えるようにして、原因がはっきりしたことに静かに安心している保守運用の担当者

理由の残らない落ち方は、追いかける側にとっていちばん心細いものです。でも、「まず OOM だったかを確かめる」と決めておくだけで、原因不明のもやもやは、ずいぶん小さくなります。 今日は、気になっていたあのサーバーで dmesg を一度たたいて、落ちた理由が OOM かどうかを確かめるだけで十分です。理由が分かれば、次の一手は自然と見えてきます。原因の入口にたどり着けた時点で、もう対応は前に進んでいます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語