OOM Killer（Out Of Memory Killer）は、サーバーの物理メモリとスワップが尽きたときに Linux カーネルがプロセスを強制終了する仕組みです。WordPress のサーバーでは MySQL/MariaDB や PHP-FPM が終了させられ、「データベース接続確立エラー」や 502 エラーとして表に出ることが多くあります。対策の中心は PHP の memory_limit を上げることではなく、PHP-FPM の同時プロセス数とデータベースのメモリ割り当てを、搭載メモリの範囲に収まるよう計算し直すことです。この記事では、ログで OOM Killer の発動を確かめる方法から、原因を可能性の高い順に切り分けて設定を直す手順までを説明します。
対象は VPS や専用サーバーなど root 権限で設定を変えられる環境です。共有レンタルサーバーではカーネルのログを見られないことが多いため、症状が続く場合はサーバー会社に問い合わせてください。
まずログで OOM Killer の発動を確かめる
サイトが落ちた原因が本当にメモリ不足かどうかは、カーネルのログで確かめられます。推測で設定を変える前に、ここを見てください。
# カーネルログから OOM Killer の記録を探す（-T で時刻を読みやすく表示）
sudo dmesg -T | grep -iE "out of memory|killed process|oom-kill"
# systemd 環境なら journal からも探せる（直近の再起動より前も含む）
sudo journalctl -k --since "2 days ago" | grep -iE "out of memory|killed process"記録があれば、次のような行が見つかります（表記はカーネルのバージョンによって多少異なります）。
Out of memory: Killed process 1234 (mysqld) total-vm:1843200kB, anon-rss:612000kB, ...括弧内が終了させられたプロセス名、anon-rss がそのプロセスが実際に使っていたメモリ量です。注意したいのは、終了させられたプロセスがメモリを食い尽くした犯人とは限らない点です。OOM Killer は「終了させたときに解放されるメモリが大きいもの」を優先して選ぶため、普段から大きなメモリを確保している mysqld が巻き添えになりがちです。犯人は、そのときに増えていた別のプロセス（多くは PHP-FPM の子プロセス群）であることがよくあります。
今のメモリの使われ方を把握する
次に、平常時と混雑時のメモリの内訳を確認します。
# 全体の使用量とスワップの有無
free -h
# メモリを多く使っているプロセスの上位
ps aux --sort=-rss | head -n 15
# PHP-FPM 子プロセス1本あたりの平均使用量（MB）
# プロセス名は環境により php-fpm8.3 / php-fpm などに変わるので合わせる
ps -C php-fpm8.3 -o rss= | awk '{s+=$1; n++} END {if (n) printf "%d本 平均 %.0f MB\n", n, s/n/1024}'free の available が数十MBまで落ち込む時間帯があるか、スワップが 0B になっていないか、PHP-FPM の子プロセスが何本・1本あたり何MBかを書き留めておきます。この数字が、後の計算の材料になります。
原因を可能性の高い順に確認する
1. PHP-FPM の pm.max_children が大きすぎる
WordPress のサーバーで最も多い原因です。PHP-FPM はアクセスが増えると子プロセスを pm.max_children の上限まで増やします。1本 80MB のプロセスが 30本並べば 2.4GB で、2GB の VPS ならそれだけで溢れます。クローラーの集中アクセスや、管理画面での重い処理が重なったときに起きやすいのが特徴です。
上限は「PHP に回せるメモリ ÷ 1本あたりの平均使用量」で決めます。たとえば 2GB の VPS で、OS とデータベースなどに 1GB を残すなら、PHP に回せるのは約 1GB です。1本 80MB なら max_children は 12 前後が目安になります。
; /etc/php/8.3/fpm/pool.d/www.conf の例（パスは PHP のバージョンと配布元で異なる）
pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
; 一定数のリクエストを処理したら子プロセスを作り直し、メモリの膨張を抑える
pm.max_requests = 500上限を下げると、混雑時は新しいリクエストが待たされたり 502/504 になったりします。それでもサーバー全体が落ちるよりは影響が小さく、ページキャッシュを入れて PHP まで届くリクエストを減らせば待ちも減ります。
2. PHP の memory_limit を上げすぎている
memory_limit は「1リクエストが使ってよい上限」で、サーバー全体の使用量を抑える設定ではありません。512M に上げて max_children が 12 なら、最悪で 6GB 使ってよいと許可したことになります。メモリ不足のエラー（Allowed memory size exhausted）が出たからといって上げ続けると、OOM Killer を招く側に回ります。
WordPress の定数 WP_MEMORY_LIMIT（通常の画面）と WP_MAX_MEMORY_LIMIT（管理画面などの重い処理）も、PHP 側の memory_limit を引き上げる方向に働きます。必要な処理が動く最小限の値にとどめ、特定のプラグインだけが大量に使う場合はその処理を見直す方が根本的です。
3. データベースのメモリ割り当てが大きすぎる
MySQL/MariaDB の innodb_buffer_pool_size は、データとインデックスをメモリに置くための領域です。専用 DB サーバー向けの「物理メモリの 70〜80%」という目安を、Web と同居する小さな VPS にそのまま当てはめると、PHP の分が残りません。同居構成ならデータベースの実サイズに少し余裕を足した程度で足ります。接続ごとに確保されるバッファもあるため、max_connections を必要以上に大きくしないことも効きます。
# /etc/mysql/mariadb.conf.d/50-server.cnf などの [mysqld] セクション（場所は環境で異なる）
[mysqld]
innodb_buffer_pool_size = 384M
max_connections = 504. スワップが無い、または小さすぎる
クラウドの VPS イメージには、スワップが設定されていないものがあります。スワップは遅いため解決策にはなりませんが、一時的なメモリの山を受け止め、OOM Killer の発動を避ける緩衝材になります。
# 1GB のスワップファイルを作る例（作業前に空き容量を確認）
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab5. 同居している他のソフトウェア
Redis で maxmemory を設定していない、全文検索エンジンを同じサーバーで動かしている、バックアッププラグインが大きなファイルを圧縮している、といった要因もあります。手順「今のメモリの使われ方を把握する」で上位に出てきたプロセスを一つずつ確認してください。Redis なら maxmemory と、上限に達したときの削除方針（maxmemory-policy）を決めておきます。
データベースを優先的に守る設定（補助策）
systemd で動かしている場合、OOMScoreAdjust でプロセスごとに「終了させられやすさ」を調整できます。データベースが落ちるとサイト全体が止まるため、値を下げて守る運用はあります。
# sudo systemctl edit mariadb（MySQL なら mysql）で作る上書き設定
[Service]
OOMScoreAdjust=-500ただし、これは終了させられる順番を変えるだけで、メモリ不足そのものは解消しません。代わりに PHP-FPM や SSH が終了させられることもあるため、ここまでの計算で総量を収めることを先に済ませてください。
設定を変えるときの進め方と確認
変更は一度に一つずつ行い、どれが効いたかを分かるようにします。設定ファイルは編集前にコピーを残し、可能ならステージング環境で負荷をかけて確かめてから本番に反映します。
# 設定ファイルの控えを取る
sudo cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak
# 構文を確認してから再起動
sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm
# 5秒ごとにメモリとスワップの動きを観察（si/so が増え続けるならまだ足りない）
vmstat 5変更後は数日から1週間ほど、混雑する時間帯の free の値と dmesg の記録を確認し、OOM Killer の記録が増えていないことを見ます。設定を詰めても足りない場合は、ページキャッシュで PHP の処理を減らすか、データベースを別サーバーに分けるか、メモリの多いプランに変える段階です。PHP やデータベースのバージョン・配布元によって設定ファイルの場所は異なります。この記事のパスは Ubuntu/Debian 系の例（2026年10月現在）なので、お使いの環境のパスに読み替えてください。
まとめ
- OOM Killer の発動は dmesg や journalctl のカーネルログで確かめる。終了させられたプロセスが犯人とは限らない。
- 最も多い原因は PHP-FPM の pm.max_children の過大。「PHP に回せるメモリ ÷ 1本あたりの使用量」で上限を決める。
- memory_limit や WP_MEMORY_LIMIT を上げることは、サーバー全体ではメモリ消費を増やす方向に働く。
- 同居構成では innodb_buffer_pool_size と max_connections を控えめにし、スワップを緩衝材として用意する。
- OOMScoreAdjust は補助策。設定はバックアップを取り、一つずつ変えて効果を観察する。