とうとうサーバーCPU高負荷の元凶(らしきもの)を発見

このところミニバードのサーバーリセットを引き起こしてしまったようだなどでちょくちょく書いていますに、利用しているレンタルサーバーミニバードの運用元ネットオウルからサーバーの高負荷を指摘され、ずっと負荷対策を検討・実施してきました。

空振りを続ける負荷対策

今回の件については、これまでに以下のような対策を実施しました。

しかしネットオウルからの回答では負荷の改善が見られないということで、ずっと更なる対策を求められ続けてきました。

ページキャッシュを導入しても負荷の改善傾向がみられないということは、外部からのアクセスが原因ではなく、サーバー内部の処理に問題がある可能性が高そうです(元々サイトのアクセス数はそれほど増えていませんし)。

ただサーバー内部の処理となると、レンタルサーバーではアクセスログとエラーログぐらいしか内部の様子を覗い知る手段がなく、しばらく手詰まりの状態が続いていました。

しかし最近、「WordPress CPU 負荷」などのキーワードで検索して出てきた情報を読みまくっていたところ、以下の記事を発見しました。

こちらの記事から情報をたぐっていくと、どうもWordPress 4.3の頃にWordPressのcronに誤ったスケジュール情報が大量に登録され、それが原因となってサーバーCPUの異常な高負荷を招いてしまう不具合があったようです。

うちのサイトで現在使っていますWordPressは4.9.1でだいぶ離れていますが、念のため該当するcron情報を確認してみることにしました。

cron情報はデータベースのoptionsテーブル内に格納されていますので、以下のようなSQLで直接参照してみました(うちのWordPressはマルチサイト構成になっていますので、テーブル名が通常とちょっと違います)。

SELECT * 
FROM `wp_2_options` 
WHERE `option_name` = 'cron'

データベースアクセスには、ミニバードで提供されていますWeb版のDB管理ツールphpMyAdminを利用しました。

これで確認した結果、驚いたことに該当するレコードのcronスケジュールに当たるoption_valueフィールドには8MB近いデータが書き込まれていることがわかりました。

これはcronのスケジュール情報としては明らかに大きすぎるデータサイズです(データはテキスト形式で格納されていますが、エクスポートしたデータをエディタで開こうとすると、エディタがしばらく固まってしまうくらいの規模です)。

これでこの肥大化したcron情報がサーバー負荷に悪影響を与えている可能性が非常に濃厚となりましたので、あとはその対処です。

一応WP Crontrolというようなcronのスケジュール情報を参照・編集するプラグインもあるようですが、スケジュールデータがこのサイズになってしまってはまともに動かない可能性が高そうです。

そこで先の記事で書かれていましたのと同じように、テーブル内の該当レコードを以下のようなSQLで一旦削除してしまうことにしました。

DELETE 
FROM `wp_2_options` 
WHERE `option_name` = 'cron'

ちょいと乱暴なやり方ですが、削除直後に確認すると該当レコードはすぐに再作成されていました。

ただし、やはり必要なスケジュールがいくつか消えてしまったようです。確認できた限りでは、以下のようなものが影響を受けました。

W3 Total Cacheの方は、プラグインを一旦停止して再び動かすことで再作成されました。

UpdraftPlus Backup/Restoreの方は無料版だと時刻が自由に設定できませんので、今晩にでもまた早朝に起きてスケジュールを再設定しておきたいと思います。

もしかしたら他にも何か足りないものがあるかもしれませんが、それは発覚した都度対応していく予定です。

この対処をした結果、サイトのレスポンスが体感できるくらい速くなりました(ページキャッシュを導入しましたので、外部からアクセスする一般ユーザーさんには実感できないかもしれませんが)。

ただサーバー内部の負荷がどうなったかはこちらからはわかりませんので、ネットオウルに連絡して負荷状況の再確認を依頼しているところです。

これで今度こそサーバーの負荷問題にケリがつけば安心して正月が迎えられそうですが、はたしてどうなりますでしょうか。

なお上記のようにデータベースを直接編集する場合には、最悪データベースが損傷してWordPressが動作不能に陥る可能性も考えられますので、事前のバックアップなどは入念に行っておいてください。