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

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

空振りを続ける負荷対策

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

  • WordPress Popular Postsプラグインの利用中止
  • W3 Total Cacheプラグインによるページキャッシュの導入
  • その他使っていないプラグインの停止
  • Broken Link Checkerプラグインのリンクチェック間隔の延長
  • サイトのアクセス拒否設定でのドメイン名使用の中止(逆引き処理で負荷がかかる場合があるという情報があったため)

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

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

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

サーバーのCPU負荷を上げる要因発見

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

[解決]Wordpressの管理画面が重すぎて死んだ時にやったこと | ゲオログ by リバネスCIO 吉田丈治

こちらの記事から情報をたぐっていくと、どうも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を利用しました。

phpMyAdmin cronスケジュール情報検索

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

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

cronスケジュール肥大の対処

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

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

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

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

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

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

  • W3 Total Cacheプラグインのページキャッシュ更新のスケジュール
  • UpdraftPlus Backup/Restoreプラグインのバックアップスケジュール

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

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

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

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

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

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

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

スポンサーリンク

フォローする

おすすめトピック(一部広告あり)

おすすめトピック(一部広告あり)