はじめに

WordPressの定期バックアッププラグイン BackWPup によるCPUバーストが原因で、インスタンスが停止する問題が発生しました。同じ現象で悩んでいる方の参考になれば幸いです。

事の発端

きっかけは、Googleから届いた一通のメールでした。

「ページがインデックスに登録されない新しい要因」

気になってサイトにアクセスしてみると…無応答。

SSHでサーバーへのログインを試みても、やはり無応答。

どうやらサーバーが死んでいるようです。

サーバーの状態確認

早速、WordPressが動いているインスタンスの状態を確認しました。インスタンス自体は正常に動いています。

「再起動」を実行すると、正常にサイトへアクセスできるようになり、サービスも復旧しました。

原因の調査

① HDD容量を疑う

まず疑ったのはディスク容量の不足です。以前、HDD容量オーバーによってログインできなくなるという問題が発生していたからです。

サーバ容量不足でWordPressにログインできなくなった話

SSHでログインし、残り容量を確認してみると…

$ df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             461M     0  461M   0% /dev
tmpfs             95M  484K   95M   1% /run
/dev/nvme0n1p1    40G   16G   23G  41% /
tmpfs            473M     0  473M   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
/dev/nvme0n1p15  124M   12M  113M  10% /boot/efi
tmpfs             95M     0   95M   0% /run/user/1000

/ には十分な空き容量（23GB）が残っており、ディスク容量は原因ではなさそうです。

② CPUバーストを疑う

次に疑ったのはCPUバーストです。 CPU使用率を確認してみると…バーストしています。

グラフを見ると、午前4時頃にスパイクが発生しています。

よくよく考えると、定期バックアップが怪しいと思い始めました。定期バックアップには BackWPup を使用しています。

③ バックアップスケジュールを確認

早速、バックアップの設定を確認してみると…ビンゴ！

4:02頃にバックアップジョブが実行されていました。

同様の問題を報告している記事も見つかりました。

参考: BackWPupでSIGXCPUエラーが発生する問題

ただし、先行事例では SIGXCPU エラーがログに表示されていましたが、私の環境ではログに該当のエラーは出ていませんでした。

ログの確認方法： バックアップ履歴の右側にあるメニューから確認できます。

④ 手動バックアップで再現確認

実際に「今すぐバックアップ」を実行して、CPUへの影響を確認しました。

結果、CPU使用率が明確に上昇しました。

おそらくこれが原因です。なぜバースト限界まで負荷がかかるのかはまだ不明ですが、対応を進めることにしました。

対応策：サーバー負荷の軽減設定

BackWPupの設定を以下のように変更しました。

設定項目	変更前	変更後
サーバーの負荷を軽減	off	minimum
最大待ち時間	デフォルト(30分)	60分

設定は右上の「高度な設定」を押下すると以下の設定が表示されます

効果の確認

設定変更後に再度バックアップを実行し、比較しました。

実行時刻	設定	CPU使用率	バックアップ時間
6:05	minimum	低い	362秒
6:35	off	高い	117秒

minimum 設定の実行結果：

警告: バックアップは362秒で作成されましたが問題がありました。正しく実行するには問題を解決してください。

off 設定の実行結果：

警告: ジョブは117秒で警告を出力し終了しました。正しく実行するには問題を解決してください。

CPU使用率は低下し、バックアップ処理時間は長くなっています。速度と安定性のトレードオフですが、サーバーダウンを防ぐことが最優先なので、このまましばらく様子を見ます。

まとめ

今回のサイト無応答の原因は、BackWPupによる定期バックアップのCPUバーストと考えています。

同じ現象でお困りの方は、以下の設定変更を試してみてください。

「サーバーの負荷を軽減」を minimum に変更
「最大待ち時間」を長めに設定（例：60分）

引き続き様子を見て、また報告します。

2025/05/30 15:40追記

今回の調査でもバーストしていました

4:00のバーストは調査前のバースト（これで落ちていてメールの通知が来ていました）
6:00のバーストが、CPU負荷軽減のバックアップ？
9:00のバーストが、CPU負荷軽減なしのバックアップでしょう
ついでに9:00のバーストでまた落ちていました
多分これが原因でしょうめ