先日、当ブログ「ラブグアバ」が一時閲覧できない状態となっていました。
なんかあまりに焦ってブログ名間違ってますね。。。その後も何回か間違えてますがw
実は以前にも閲覧不能状態となったことがあり、そのときはWordPressブログからはてなブログに移転したくらい深刻な状況でした。
「ラブグアバ」復活しました！WordPressブログの更新停止から再開までの経緯
今回も似たような症状だったので、「これはもしかして前回の悪夢の再来か…？」とものすごく嫌な予感がしました。
前回の対処方法なんかも参考にしつつ、いろいろ調べていく中で直接的な原因が特定でき、なんとか復旧することができました。
どうやら、WordPressの予約投稿などに使われるwp-cronの仕組みと、プラグイン「SNS Count Cache」の相性の悪さが原因だったようです。
事の顛末をご紹介したいと思います。
※なお、これは当ブログで発生した事象と対策であり、SNS Count Cacheプラグインの不具合だ！このプラグインが悪い！という意図は全くありません。あくまで一例として見てください。
発生した事象
事象としては、個別記事ページを開いてもページの先頭部分しか読み込まれない状態で表示される、という状況でした。
また、ブログの表示速度が全体的に遅く、ページ表示に時間がかかった挙句、結局一部しか表示されないという感じ。
前回はサーバリソース制限されてWordPress管理画面がほとんど使えませんでした。
今回はリソース制限はされてないのでまだマシですが、事象としては前回と同じような状況です。。。
早く対処しないとまたリソース制限とかされるかもしれない。
恐怖に怯えながらも、とりあえず前回何をしたかなどを振り返ったり、ネット情報を参考にしながら対処していくことにしました。
SNS Count Cacheプラグインの削除→とりあえず表示されるように
実は以前の対応で、あるプラグインを削除したらやや改善されたという実績がありました。そのプラグインが「SNS Count Cache」だったのです。
前回復活後に再度インストールしていたのですが、今回もう一度削除することにしました。
WordPress管理画面からは消せなかった（多分サーバーへの負荷が高かったため）ので、FTP接続して無理矢理SNS Count Cacheプラグインのディレクトリごと削除しました。
これでとりあえずブログが表示されるようにはなりました。が、まだいつもよりレスポンスが悪く、もっさりしております。
というわけでもう少し調査します。
SNS Count Cacheのスケジュールが怪しい
SNS Count Cacheプラグインを停止したら改善されたということで、それ絡みでCPU負荷が高まっている事象がなかったかググってみたら、こんな情報を見つけました。
WP4.3.0にCPU負荷とメモリ消費が増加する不具合？対処してみた | ぽぽづれ。
これによると、WordPress4.3.0のバグが原因でcron処理用のスケジュール（ジョブ）が大量に登録され、その結果CPU負荷が高まるという内容です。
で、その大量登録されたcronスケジュールというのが「SNS Count Cache」のスケジュールだと。
む？これは怪しい。私はWordPress4.3.0ではないですが、SNS Count Cacheというのが気になる。
SNS Count Cacheは定期的にSNSカウント数をキャッシュする機能があり、cron機能も使っているはずなので。
SNS Count Cacheのジョブが大量に登録されている
これは一度自分のcronのジョブ登録内容も確認したほうがいいと思い、上記記事に書かれていたプラグイン「Pz-CronCheck」を使って確認してみることにしました。
※公式なものではなく、簡易的なプラグインのようです。
そしてcronをチェックしてみたところ、、、
▼うわああああ！なんかめちゃくちゃ登録されてるー！
量が多すぎてスクロールバーがすごく小さく表示されてます。。。
ぱっと見で「scc_share～」という文字列が多かったので画面内で検索してみたら、3万個以上ヒットしました。
sccって、間違いなくSNS Count Cacheだよな…。なぜだか理由はわかりませんが、SNS Count Cacheのジョブが死ぬほど登録されています。これが原因か。
wp_optionsテーブルのcronレコードを削除する
こりゃいかんということで、この大量登録されたジョブを削除することにしました。
このジョブは、WordPressのDBの「wp_options」というテーブルに登録されています。option_name = ‘cron’というのがそれです。
※wp_optionsの「wp」の部分は接頭語なので、初期設定で変更している場合は異なる可能性があります。デフォルトは「wp」のはずです。
消し方としては、プラグインを使うか、DBを直接編集するかが考えられます。
WP-Cron Dashboardプラグインを使う
WP-Cron Dashboard — WordPress Plugins
まずは上記プラグインを使って削除を試みました。
が、このプラグインだとジョブを1つずつしか消せないため、あまりに数が多すぎて現実的でないので断念しました。
DBのwp_optionsテーブルを編集する
こうなったら仕方ありません。あまりやりたくありませんが、wp_optionsテーブルを直接編集することにします。
phpMyAdminを利用します。phpMyAdminの詳しい使い方はここでは省略しますが、やったことは以下です。
- phpMyAdminでWordPressのDBにアクセス。
- 念のため、DB内容をエクスポートしておく。
- SQLタブを押下し、次のSQLを実行。「delete from wp_options where option_name = ‘cron’;」
これ、3の手順があまりよろしくないと思いますが、削除する条件を書くのがちょっと難易度高そうだったので、cronのレコードごと削除してしまいました。
本当は削除するキーをきちっと調べてSQLの条件に含めるべきだと思うので、このやり方は非推奨です。
ただ、削除してもcronのレコードはすぐに勝手に作成されました。WordPress本体のバージョン確認などのジョブが自動的に作成されるようです。
削除後は元通りのレスポンスに
削除した後、前述のPz-CronCheckプラグインやWP-Cron Dashboardプラグインで確認したところ、今度は1画面で収まる程度のジョブ数が登録されていました。
そしてブログのレスポンスも元通りになりました。やはり大量のジョブが登録されていたことが原因だったようです。
ジョブ登録されているプラグインを確認（BackWPupなど）
ブログの状態は回復したものの、私は1つ気になることがありました。
それは、プラグインの中に自分で時間を設定しているものがあることです。具体的には、定期的にWordPressのバックアップを取ってくれるBackWPupプラグインです。
プラグインの詳細については以下を参考にしてください。
WordPressのDBやファイルをバックアップしてくれるプラグイン「BackWPup」の設定方法
このBackWPupのジョブはどうなってるんだろ…と思って確認してみました。
すると、次回の実行予定日が「1970年1月1日 ○時○分」になっていました。やはりcronデータを削除したことで設定がおかしくなってしまったようです。
対処方法としては、一度手動で実行することにより、次回実行予定日が設定通りになりました。
他にもいくつか気になるものがありましたが、以下のように特に問題はありませんでした。
- 記事の予約投稿→特に問題なく投稿された
- ブログ過去記事を定期的にツイートしてくれる不動産Tweet Old Postプラグイン→特に問題なくツイートされている
- 定期的にリンク切れを確認してくれるBroken Link Checkerプラグイン→勝手にcronに再登録されたので問題なし
まとめ
というわけで、ブログが見れなくなった原因と対処方法についてご紹介しました。
冒頭にも書きましたが、SNS Count Cacheプラグインが必ずしも悪いとは考えていません。これまでは特に問題なく動いていましたし、このプラグイン以外の私のWordPress環境に問題があるのかもしれませんので。
ただ、前回のブログ停止した際もこのプラグインがなんらかの影響があったのは間違いありませんし、今回も同じ原因だと推察されます。少なくとも当ブログでは今回のような事象が起こるリスクがあると判断しました。
なので、当ブログではこの「SNS Count Cache」プラグインは当面使わないことにしました。非常に便利なプラグインではあるので名残惜しいのですが。。。
やはり、キャッシュ系プラグインというのは利用するのが難しいなーと痛感しました。
＜関連記事＞
WordPressのDBやファイルをバックアップしてくれるプラグイン「BackWPup」の設定方法
「ラブグアバ」復活しました！WordPressブログの更新停止から再開までの経緯
WordPressプラグイン SNS Count Cacheを使えばブログのツイート数やはてブ数を高速表示できるよ！
WordPress Perfect GuideBook 4.x対応版