ある日、自分で運営しているWordPressサイトに突然アクセスできなくなりました。ブラウザには「ERR_CONNECTION_TIMED_OUT」、そしてAWSからは「ステータスチェックの失敗」というアラート通知。AWS Lightsailの1GBプランで動かしていたサイトが、メモリ起因でダウンしていたのです。
この記事では、その障害を切り分けて、プラン変更（=月額アップ）をせずに無料で根本対処した一部始終を、実際に打ったコマンド付きで記録します。同じく1GBのLightsailでWordPressを運用していて、急にサイトが落ちて困っている方の助けになれば幸いです。
起きた症状
最初の異変はブラウザでした。サイトを開こうとすると、いつまでも読み込まれずにこのエラーが出ます。
「このサイトにアクセスできません」「応答時間が長すぎます」「ERR_CONNECTION_TIMED_OUT」
これは「サーバーに接続を試みたが、時間内に応答が返ってこなかった」という意味です。サーバーが完全に黙り込んでいる状態を疑います。
続いてLightsailから、こんな趣旨のアラートメールが届いていました。
ステータスチェックの失敗 の通知。過去5分以内の対象リソースのステータスチェックの失敗が、しきい値を超過しました。
ステータスチェックの失敗というのは、Lightsail（AWS）側から見て「このインスタンス、正常に応答してないよ」というサインです。OSレベルで応答不能になっているときに出ます。
手元のPCのターミナルから、サーバーに生存確認（ping）を打ってみると、すべて応答なしでした。
ping xxxxxxxxxxxxxxxxx
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
...
--- ping statistics ---
340 packets transmitted, 0 packets received, 100.0% packet loss100% packet loss。サーバーは完全に応答していません。この時点で「サーバー本体が落ちている」とほぼ確定です。
応急処置：まずはインスタンスを再起動
サーバーが応答不能になっているときの第一手は、Lightsailコンソールからのインスタンス再起動です。手順はシンプルです。
- Lightsailコンソールで対象インスタンスのページを開く
- 「停止」を押す（ステータスが「停止済み」になるまで待つ）
- 「開始」を押して起動する
- ステータスが「実行中」、かつステータスチェックが回復するまで2〜3分待つ
ここで注意点がひとつ。静的IPをアタッチしていれば、停止→起動してもIPアドレスは変わりません。逆に静的IPを使っていない場合、再起動でグローバルIPが変わってしまうので要注意です（本番運用なら静的IPは必須です）。
再起動後、改めてpingを打ち直して応答が返ってくれば復活です。実際、これでサイトは無事に表示されるようになり、WordPress管理画面にもログインできました。
しかし、再起動だけでは再発する
ここで終わらせると、また同じことが起きます。再起動は「とりあえず起こした」だけで、なぜ落ちたのかは何も解決していないからです。実際このサイトは過去にもメモリ不足でApacheが落ちた経緯がありました。
そこで、サーバーの中に入って原因を調べます。ここからはLightsailの「ブラウザSSH」(コンソールの「SSHを使用して接続」ボタン)で、サーバーの中に入って作業します。
原因調査①：メモリの状態を見る
まずはメモリがどれくらい使われているかを確認します。Linuxでは free -m コマンドでメモリの使用状況をMB単位で見られます。
free -m
total used free shared buff/cache available
Mem: 945 487 369 49 273 457
Swap: 1023 0 1023読み方のポイントは available（利用可能メモリ） の列です。ここが残りの実質的な余裕を表します。
- Mem total 945MB：物理メモリは約1GB（1GBプラン）
- available 457MB：この瞬間に使える余裕は457MB
- Swap 1023MB：スワップ（メモリが足りないとき一時退避する領域）は約1GB設定済み、使用は0
スワップは既に1GBありました。つまり「スワップを足せば解決」という単純な話ではありません。スワップ込みでも落ちたということは、瞬間的にメモリを一気に使い切っている可能性が高いと読めます。では、何がメモリを食っているのか。
原因調査②：何がメモリを食っているか
メモリ使用量の多いプロセス順に並べて表示します。ps aux にソート指定を付けたコマンドです。
ps aux --sort=-%mem | head -10結果がこちらです（一部抜粋）。
USER PID %MEM RSS COMMAND
mysql 522 15.1 146188 /usr/sbin/mariadbd
www-data 600 8.6 83360 /usr/sbin/apache2 -k start
www-data 536 8.1 79008 /usr/sbin/apache2 -k start
www-data 535 7.9 76516 /usr/sbin/apache2 -k start
www-data 533 7.6 73764 /usr/sbin/apache2 -k start
www-data 602 7.5 73232 /usr/sbin/apache2 -k start
www-data 534 7.2 69928 /usr/sbin/apache2 -k start
www-data 532 7.0 68048 /usr/sbin/apache2 -k start
www-data 601 6.2 60276 /usr/sbin/apache2 -k startここで犯人が見えました。Apache（apache2）のプロセスが7つも走っていて、それぞれ60〜83MBを消費しています。Apacheだけで合計500MB以上。これにMySQL（mariadbd）の146MBを足すと、平常時で既に650MB前後を使っている計算です。945MBしかないメモリの大半が常に埋まっている状態でした。
WordPressはPHPで動きますが、Apacheの各プロセスがそのPHPを抱え込むため、1プロセスあたり70〜80MBと太りやすいのです。この状態でアクセスが少し増え、Apacheのプロセスがあと数個生まれただけで、メモリを使い切ってスワップに逃げ、それでも足りずにOSごと応答不能になる——これが落ちる流れでした。
真犯人：Apacheの「prefork」設定がデフォルトのまま
Apacheには動作モード（MPM）があります。どのモードかを確認します。
sudo apache2ctl -V | grep -i mpm
Server MPM: preforkpreforkは「1つのリクエストにつき1プロセスを使う」方式です。だからこそ、同時に起動できるプロセス数の上限が、そのままメモリ消費の上限になります。その設定を見てみます。
cat /etc/apache2/mods-available/mpm_prefork.conf
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 150
MaxConnectionsPerChild 0問題はここです。MaxRequestWorkers 150。これは「最大150個のApacheプロセスを起動してよい」というDebian系のデフォルト値です。1プロセス約80MBで計算すると、150 × 80MB ＝ 約12GB分のメモリ使用を許可していることになります。1GBしかないサーバーでこれを許せば、アクセスが増えた瞬間にメモリを食い尽くして落ちるのは当然でした。
加えて MaxConnectionsPerChild 0 も良くありません。これは「プロセスを再起動せず使い続ける」設定で、メモリリークがじわじわ蓄積してプロセスが太り続ける原因になります。
対処：1GBメモリに合わせてprefork設定を絞る
では、メモリを使い切る前に頭打ちになるよう設定を変更します。アクセスが殺到しても「重くなる」だけで済み、「OSごと落ちる」のを防ぐのが狙いです。
手順1：まず設定ファイルをバックアップ（失敗しても戻せるように）
sudo cp /etc/apache2/mods-available/mpm_prefork.conf /etc/apache2/mods-available/mpm_prefork.conf.bak手順2：設定を1GB向けに書き換える
sudo tee /etc/apache2/mods-available/mpm_prefork.conf > /dev/null <<'EOF'
# prefork MPM - tuned for 1GB RAM
<IfModule mpm_prefork_module>
StartServers 2
MinSpareServers 2
MaxSpareServers 5
MaxRequestWorkers 8
MaxConnectionsPerChild 1000
</IfModule>
EOF変更の意図はこうです。
- MaxRequestWorkers 8：Apacheは最大8プロセスで頭打ち。8 × 約80MB ＝ 640MB程度に抑えられ、MySQLの146MBと足してもメモリ内に収まる
- MaxConnectionsPerChild 1000：プロセスが1000リクエストを処理したら再起動。メモリリークでじわじわ太るのを防ぐ
- StartServers / MinSpareServers / MaxSpareServers：待機プロセス数も少なめにして、平常時のメモリ消費を抑える
手順3：書き換えを確認
cat /etc/apache2/mods-available/mpm_prefork.conf手順4：設定ファイルに文法エラーがないかチェック（これが最重要。エラーのまま再起動するとApacheが起動できず、サイトが再び落ちます）
sudo apache2ctl configtestここで Syntax OK と表示されることを必ず確認してください。出なければ、設定ファイルのどこかにミスがあります。
手順5：Apacheを再起動して設定を反映
sudo systemctl restart apache2結果：メモリに余裕が生まれた
再起動後、もう一度メモリを確認します。
free -m
total used free shared buff/cache available
Mem: 945 409 442 37 267 535
Swap: 1023 0 1023変化が数字に出ました。
- 利用可能メモリ（available）：457MB → 535MB に増加
- 使用中メモリ（used）：487MB → 409MB に減少
Apacheのプロセス数が絞られたぶん、メモリに余裕が生まれました。そしてアクセスが増えてもApacheは最大8プロセスで止まるので、メモリを使い切ってOSごと落ちる事態を防げるようになりました。これで根本対処は完了です。
補足：MaxRequestWorkersの値は微調整できる
今回設定した MaxRequestWorkers 8 は、1GBメモリ向けにかなり安全寄りに絞った値です。もしアクセスが集中する時間帯に「サイトが重い・つながりにくい」と感じることがあれば、10〜12くらいまでは上げる余地があります。その場合は同じファイルを編集して、再び configtest → restart の流れで反映します。
逆に、しばらく様子を見て数日落ちなければ、この設定で安定していると判断してよいでしょう。サイトの規模やアクセス数に合わせて、自分の環境の「ちょうどいい上限」を探るのがコツです。
まとめ
今回の障害対応を一行でまとめると、こうなります。
ダウンの原因はメモリ不足だったが、プラン変更（有料）ではなく、Apacheのprefork設定を見直すこと（無料）で根本対処できた。
ポイントを整理します。
- ERR_CONNECTION_TIMED_OUT＋ステータスチェック失敗＋ping全ロス → サーバー本体のダウンを疑う
- 再起動は応急処置。それだけでは再発するので必ず原因を調べる
free -mでメモリ、ps aux --sort=-%memで犯人プロセスを特定- 1GB環境でApacheのMaxRequestWorkersがデフォルト150のままは過大。8前後に絞る
- 設定変更後は
configtestで文法チェックしてから再起動
1GBのLightsailでWordPressを動かすと、メモリは常にギリギリです。プランを上げる前に、まずApacheの設定を環境に合わせて見直すだけで、月額を増やさずに安定させられるケースは多いはずです。同じ症状で困っている方の参考になれば嬉しいです。