【怪奇現象】サーバーが「勝手に」死んでいる…？
こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回の記事で、SSH接続や権限周りのトラブルは解決できたでしょうか？
サーバー構築の恐ろしいところは、やっと動いた！と思って安心した数日後、あるいは数ヶ月後に「第2の波」がやってくるところです。
それは、接続エラーのような明確な拒絶ではなく、もっと陰湿で、原因が分かりにくい不具合です。
先生、聞いてください…。
この前作ったWordPressのサイト、朝起きたら「データベース接続確立エラー」になって止まっていたんです。
再起動したら直ったんですけど、数日経つとまた止まるんです。
誰も触っていないのに、幽霊でもいるんでしょうか…？（怖）
それは幽霊じゃないわ。
Linuxの中に住んでいる「暗殺者（Killer）」の仕業よ。
今回は、サーバーが稼働し始めた後に直面する「リソース不足」「プロセス異常」「Webサーバーのエラー」といった、より実践的なトラブルシューティングを伝授するわ。
この記事では、以下の5つの「運用トラブル」を深掘りします。
- 【メモリ編】 アプリが勝手に落ちる犯人「OOM Killer」とSwap対策
- 【ディスク編】 「容量不足」の本当の恐怖と、見えないゴミファイルの掃除
- 【負荷編】 サーバーが激重！
topコマンドで犯人を特定する技術 - 【Web編】 502 Bad Gateway / 403 Forbidden の正体
- 【自動化編】 Cronが動かない時に見るべき「環境変数」の罠
これを読めば、あなたのサーバー管理スキルは「初心者」を卒業し、トラブルを未然に防ぐ「運用者」の領域へと足を踏み入れることができます。
第1章：メモリ不足と「OOM Killer」の暗躍
「何もしていないのにMySQLが落ちている」。
低スペックのVPS（メモリ512MB〜1GB）を使っている場合、原因の9割はメモリ不足です。
1-1. 犯行現場の証拠を押さえる
Linuxには、メモリが物理的に足りなくなった時、システム全体が共倒れするのを防ぐために、「メモリを食っている行儀の悪いプロセスを強制的に殺す」という機能が備わっています。
これが「OOM Killer (Out of Memory Killer)」です。
まずは、本当に彼が犯人なのか、システムログ（dmesg）を確認しましょう。
# OOM Killerの痕跡を探す（iは大小文字区別なし） sudo dmesg | grep -i oom
もし以下のような赤い文字が出てきたら、確定です。
Out of memory: Killed process 1234 (mysqld) total-vm:...
「mysqld（データベース）」がメモリ不足のために殺害されたことが記録されています。
1-2. 解決策：Swap（スワップ）領域を作る
メモリを増設（プラン変更）するのが一番ですが、コストがかかります。
無料で行える対策として、ディスクの一部をメモリ代わりにする「Swapファイル」を作成しましょう。
多くのVPSの初期設定ではSwapが無効（0GB）になっています。
【Swap作成の3ステップ】
ここでは安全な「2GB」のSwapファイルを作成します。
# 1. 空のファイルを作成（2G = 2048MB） sudo fallocate -l 2G /swapfile # 2. 権限を「rootのみ」に制限（セキュリティ必須） sudo chmod 600 /swapfile # 3. Swap領域としてフォーマットし、有効化 sudo mkswap /swapfile sudo swapon /swapfile
これで応急処置は完了です。free -h コマンドを打って、Swap: 2.0Gi と表示されれば成功です。
※再起動後も有効にするには /etc/fstab への追記が必要ですが、まずはこれで落ちなくなるか様子を見ましょう。
Swapはあくまで「保険」よ。
もしSwapを使っても頻繁に落ちるなら、それはサーバーのスペック不足が明白ね。
その時は、メモリ容量の大きい上位プランや、他社のハイスペックなVPSへの引っ越しを検討するタイミングよ。
▼ハイスペックでも安い！おすすめVPSはこちら
第2章：ディスク容量不足（Disk Full）のミステリー
「No space left on device」
このエラーが出ると、ファイルの保存はおろか、Tabキーによるコマンド補完すら効かなくなります。
2-1. 犯人探しの基本コマンド
まずはどこがパンパンなのか調べます。
# 全体の使用率を確認 df -h
/ (ルート) が100%になっていたら緊急事態です。
次に、どのディレクトリが容量を食っているか特定します。
# ルート直下のディレクトリごとの容量を表示（計算に少し時間がかかります） sudo du -sh /*
多くの場合、犯人は以下のいずれかに潜んでいます。
/var/log：ログファイルの肥大化/var/lib/mysql：データベースのバイナリログ/home：ユーザーがアップロードしたファイル
2-2. 「消したはずなのに容量が減らない」怪奇現象
先生！巨大なログファイルを見つけて削除（rm）したんです。
でも df -h で見ると、まだ「使用率100%」のままなんです！
どうなってるんですか！？
これは初心者が必ずハマる罠ね。
Linuxでは、「プロセスが掴んでいるファイルを削除しても、ディスク領域は解放されない」という仕様があるの。
例えば、Webサーバーが書き込み中のログファイルを無理やり消しても、Webサーバー自体を再起動するまで、そのファイルは「亡霊」として容量を食い続けるわ。
【亡霊ファイルの探し方】
lsof コマンドで、削除されたのに掴まれているファイル（deleted）を探します。
# 削除済み(deleted)なのに開かれているファイルを探す sudo lsof / | grep deleted
もしここで巨大なログファイルが出てきたら、そのファイルを掴んでいるプロセス（NginxやApacheなど）を再起動してください。sudo systemctl restart nginx などを実行した瞬間、嘘のように空き容量が戻ってきます。
2-3. journalログの掃除
Ubuntuでは systemd-journald という機能がログを溜め込んでおり、これが数GBになっていることがよくあります。
# ジャーナルログの容量確認 journalctl --disk-usage # 1秒で掃除（古いログを捨てて100MBまで縮小） sudo journalctl --vacuum-size=100M
第3章：サーバーが激重！負荷の正体を見破れ
「サイトの表示が遅い」「コマンドの反応が鈍い」。
そんな時は top コマンドでサーバーの健康診断を行います。
3-1. Load Average（ロードアベレージ）を見る
top を実行し、右上の 「load average: 0.50, 1.20, 2.00」 という数字に注目してください。
これは左から「1分間、5分間、15分間」の平均負荷を表します。
【危険信号の目安】
CPUのコア数（nprocコマンドで確認）が基準です。
- 1コアのVPSの場合： 「1.0」を超えると行列ができ始めている。「3.0」を超えると操作困難。
- 2コアのVPSの場合： 「2.0」が基準線。
3-2. %CPU と %WA の違い
負荷が高い時、CPUが何をしているかが重要です。
- %us (User) が高い：
プログラム（PHPやPythonなど）が計算処理で忙しい状態。コードの効率化やCPU増強が必要。 - %wa (IO Wait) が高い：
CPUは暇なのに、ディスクの読み書き（I/O）が遅すぎて待たされている状態。DBへのアクセス過多や、ディスク故障の可能性があります。
第4章：Webサーバーの「50x」「40x」エラー
ブラウザに表示されるエラーコードは、問題の切り分けに役立つ最大のヒントです。
4-1. 502 Bad Gateway（Nginx）
WordPress環境で最も多いエラーです。
これは「Nginx（受付係）は元気だけど、後ろにいるPHP（処理係）が返事をしない」という意味です。
【対策】
PHP-FPMが落ちている可能性が高いです。
# PHPの状態確認 sudo systemctl status php8.1-fpm # バージョンは環境に合わせて # 再起動 sudo systemctl restart php8.1-fpm
それでも直らない場合、Nginxの設定ファイル（/etc/nginx/sites-available/...）で指定しているソケットパス（unix:/run/php/...）と、実際のPHPの設定が食い違っていることがよくあります。
4-2. 403 Forbidden（閲覧禁止）
「権限がありません」というエラーです。
Webサーバーの実行ユーザー（通常は www-data）が、ファイルやディレクトリを読み取れない状態です。
【対策】
公開ディレクトリの所有権を www-data に渡します。
# 所有者を変更（-Rで再帰的に）
sudo chown -R www-data:www-data /var/www/html
# ディレクトリは755、ファイルは644に修正
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
4-3. 設定ファイルの構文エラーチェック
設定ファイルをいじった後、再起動したら動かなくなった時は、必ず「構文チェック」を行います。
# Nginxの場合 sudo nginx -t # Apacheの場合 sudo apache2ctl configtest
「Syntax OK」と出れば安心ですが、エラーが出た場合は「何行目の記述が間違っているか」を教えてくれます。
第5章：Cron（自動実行）が動かない罠
「コマンドラインで手動実行すると動くのに、Cronに登録すると動かない」。
これはLinux七不思議の一つと言われるほど多発するトラブルです。
原因：環境変数（PATH）が違う
私たちがターミナルでログインしている時は、便利な「環境変数（PATH）」が読み込まれていますが、Cronは「裸の状態」で実行されます。
つまり、単に php と書いても、「phpコマンドがどこにあるか知らないよ」となってしまうのです。
【対策：絶対パスを使う】
Cronに記述する際は、必ずコマンドをフルパス（絶対パス）で書きます。
# × ダメな例 0 4 * * * php /var/www/backup.php # ○ 正しい例（which php で場所を確認） 0 4 * * * /usr/bin/php /var/www/backup.php
また、Cronの実行ログはデフォルトでは表示されません。
トラブル時は syslog を確認するか、標準出力をファイルに書き出す設定にしてデバッグします。
# エラー内容をファイルに吐き出させるデバッグ術 0 4 * * * /usr/bin/php /var/www/backup.php > /tmp/cron_debug.log 2>&1
まとめ：トラブルは「サーバーの健康診断」
いかがでしたか？
今回紹介した「メモリ」「ディスク」「負荷」「Webエラー」「Cron」の5つは、サーバーを長く運用していれば必ず出くわす壁です。
しかし、これらのトラブルシューティングを経験するたびに、あなたは「OSがどうやってリソースを管理しているか」「Webサーバーがどう連携しているか」という深い理解を得ることができます。
エラーが出たら、まずはログを見る。そして、この記事の対処法を試してみてください。
もし「設定をいじりすぎて修復不可能になった…」という場合は、潔く「サーバー再構築」をするのも一つの手です。
VPSなら数分で新品の環境が手に入りますからね。
▼失敗しても安心！何度でも再構築できるVPSはこちら
コメント