WordPressの管理画面が急に遅くなる
先日studio9のデザインをリニューアルしたわけですが、その直後からサイトが急に重くなり、メモリが食い尽くされ、CPUはブンブン回り、管理ページの遷移に１０秒以上かかるようになりました。。
記事の上書き保存や更新に10秒以上待たされる感じです。。
いろいろあってようやく解決したのでメモを残しておきます。
ちなみに私はサーバー周りぜんぜん詳しくないので恐らく個別のご質問には答えられない可能性が高いし、この作業で不具合が起きても何も保証できませんのでご了承下さい。。^^;
解決に当たっては下記リンクの内容が大変役立ちました。というか紹介している方法自体はまったく同じ方法です。ですのでここでは私の環境を中心にご紹介していきます。
＊＊追記(15.09.16)＊＊
WordPress 4.3.1のアップデートが始まりましたね。今回紹介しているバグも修正され、セキュリティアップデートも入っていますので4.3の方は早めにアップデートすることをオススメします。
- WordPress 4.3でメモリ消費量増大・CPU高負荷になる重大なバグあり。直し方を一応解説。
サーバーの環境と不具合の発生
サーバーの環境
studio9のサーバー（このサーバーも）は さくらのVPS 4G(SSD) で運用しており、CentOS(6.7) + Nginx(1.9) + php-fpm + Mysql(5.5) で構成しています。
月間アクセスは５０～６０万PVくらい。
異常が起こる前は平常時、CPU負荷が２０～３０％、メモリも１Gくらいの消費で全然余裕をもって運用できている状態でした。
不具合が発生したきっかけ
ローカル環境(XAMPP)でテストしながらテーマを大規模に改修し、問題無さそうなので本番環境に移行。
ローカルでもWordpress4.3.0にアップグレードした状態でテストしていたため問題は無いと考えテーマ更新と同時にWordpressのアップデートも実施（4.2.4 ⇒ 4.3）。
移行直後から、ん？なんだか管理画面が遅いぞ？と思いつつ、function.php側にいろいろ機能追加したためまずはこちらを疑います。
しかし特に異常はなさそう。
pfp-fpmがメモリを食い尽くして不足する
いよいよおかしいと思い htop で確認してみるとphp-fpmのプロセスがブンブン回っていて、１プロセス100～200MBのメモリを食いつつ、CPUも100％近くなることが多々。
普段は1GB程度で落ち着いているのに4GB食い尽くしてスワップまで発生する始末。
php-fpmのエラーログ眺めてみるとこんな感じだったので↓、pm.max_childrenやらpm.max_spare_serversをいろいろ変えても状況はほとんど変わらず。
vi /var/log/php-fpm/error.log WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 2 idle, and 21 total children WARNING: [pool www] server reached pm.max_children setting (35), consider raising it
Googleアナリティクスの「サーバーの平均応答時間」も平時0.1秒くらいだったのが0.7秒くらいに激増。ひどい日は1.15秒と平時の10倍ほど遅くなってしまいました。
WordPressをダウングレードしてみる
やっぱりWordpress4.3がおかしいのでは？？と疑い始めて、正常に動いていたWordPress4.2.4へ手動でダウングレード（＠本番環境）。
- 《意外と簡単！》WordPressのバージョンをダウングレードする方法
やっぱりだめ。
ダウングレードも効果なし
ダウングレードしても不具合が回復しないってことでWordpressの異常の線はひとまず置いておくことにしたが、これが後々泥沼にハマるきっかけだった。
データベース側も特にこれといった異常は見られない。
---
ここで完全に詰んだわ。。と途方に暮れつつ、デバッグモードに切り替えて細かなエラーをチビチビ消していくもいっこうに効果は現れず。
php, nginxなどシステムをアップグレード
ローカル（XAMPP）では動いているのに本番では遅いって？？ということで、phpのバージョンやらそもそもNginxとApacheで極端に違いが出るのかしら？？
なんて思いつつ、あきらかにphp回りがおかしそうなので本番環境のphpを 5.4+APC から 5.5+OPchace に変えたりNginxを1.9.4にアップグレードしたり（アップグレード前は確か1.7.x）とサーバーの中身も変更。
- CentOSのPHPを5.4から5.5にアップデート。OPcacheとAPCuも設定
しかし、効果はなし
---
状況としては、キャッシュの表示は上手くいっており（w3 total cacheを使用）、キャッシュを通さないような管理画面からのアクセスや、キャッシュクリア直後にめちゃ重くなるのでWEBサーバーではなく、Wordpressが良くないことは間違いなさそう。
Query MonitorでWordpressを調査
じゃぁWordpress内部をデバックするのってどうすりゃいいんだろと思い調べてみると「Query Monitor」っていうプラグインがあるらしい。そこで「Query Monitor」で調べてみると１つ明らかにおかしなクエリがある。。
- WordPressのデバッグプラグイン「Query Monitor」をサイト制作・カスタマイズに役立てよう
詳しい内容は良くわからないのですが（汗、中身見るとwp_optionsにWordpressのスケジュール機能をアップデートするような内容で明らかに異常。そこをたどってみると「wp_batch_split_terms」という項目以降延々と同じような設定が続いてる。。
この「wp_batch_split_terms」以降同じような設定が延々と続いてる
明らかにおかしいでしょこれ。似たようなスケジュールの設定（？）が数千行くらい？続いてます。上のスクショに見えているのはほんの一部でずーっと下まで続いてます。（テキストファイルにしたら３MB以上だった）
これで「wp_batch_split_terms」でググッたら上記の記事が引っかかり無事解決というわけ。
- WordPress 4.3でメモリ消費量増大・CPU高負荷になる重大なバグあり。直し方を一応解説。
ありがたやー。
具体的な回復手順
ちなみに、この時点ではまだダウングレードしたWordpress 4.2.4でしたが藁にもすがる思いで4.3にアップデートし、リンク先にもあるようにWordpressのコアファイルを編集します。
＊本体のプログラムを編集するので必ずバックアップなどとって作業してください
wp-includes/taxonomy.phpを修正
まずは、wp-includes/taxonomy.php をテキストエディタなどで開いて、4448行目の引数の部分↓
wp_schedule_single_event( 'wp_batch_split_terms', time() + MINUTE_IN_SECONDS );
を以下のように入れ替えます。
引数が逆だったなんて。。
wp_schedule_single_event( time() + MINUTE_IN_SECONDS, 'wp_batch_split_terms' );
＊＊追記(15.09.16)＊＊
WordPress 4.3.1へのアップデートで上記のバグは修正されてます。この修正をしたかたはそのまま4.3.1へアップデートすれば何もしなくてOK。
下記mu-pluginsに修正用ファイルを入れた方はfix.phpはそのまま削除しても大丈夫です。
wp-contentに修正用プログラムを置く
続いて、
/wp-content/ の中に「mu-plugins」というフォルダを新規に作り（環境によってはすでにあるのかも。私の場合XAMPP環境には無かったけど本番環境にはなぜかあった）、その中に修正用のファイルを入れます。
「fix.php」というファイルをテキストエディタなどで作り、/wp-content/mu-plugins/の中に保存。
<?php
function clear_bad_cron_entries() {
// Fix incorrect cron entries for term splitting
$cron_array = _get_cron_array();
if ( isset( $cron_array['wp_batch_split_terms'] ) ) {
unset( $cron_array['wp_batch_split_terms'] );
_set_cron_array( $cron_array );
}
}
clear_bad_cron_entries();
最後の「 ?> 」はいらないの？とドキドキしましたがいらない模様。ちなみにここの処理は何をやっているのかはよくわかっていません（汗
＊＊追記(15.09.16)＊＊
上にも書きましたがWordpress 4.3.1へのアップデートで上記のバグは修正されてます。この修正をしたかたはそのまま4.3.1へアップデートすれば何もしなくてOK。
下記mu-pluginsに修正用ファイルを入れた方はfix.phpはそのまま削除しても大丈夫です。
アクセスしなおすだけ！
あとはTOPページにアクセスしなおせばあら不思議。
すっかり軽くなりました！
php-fpmが急に落ち着きを取り戻し、CPUもメモリも使用率が一気に下がり、管理画面の遷移もサクサク！
念のためphp-fpmを再起動し、
service php-fpm restart
各種キャッシュも削除したら作業完了。
今のところ非常に快適です。
ダウングレードしたのに直らなかったのが未だに謎ではあります。。
まとめ
ということで、ここ１週間くらい冷や汗流しながら対応した内容をギュッとまとめてみました。
ちなみにローカルのXAMPP環境ではこのような異常は見られず、何がトリガーで起こっているのかはわかりません。。
ローカルでテストしたといっても本番と違う環境ではこのようにどハマりすることもあるんだなぁと実感しました^^;
vagrantとかでローカル側にも同じ仮想環境作ったほうが良いのかなぁと思ったり。でもXAMPPの手軽さは捨てがたいんだよなぁ。
とりあえず大変勉強になりました。
早急に4.3.1でバグ修正してもらえるといいですね。＊修正入りました！