WordPressが重い症状が解決！原因はSNS Count Cache？

ここ1年くらいの懸案だったWordPress（別サイト）が重い症状が解決しました。

WordPressが重い原因は環境により様々だと思いますが、同じ原因でトラブルが発生している方がいるかもしれないので情報を共有しておこうと思います。

このページで紹介する改善方法は、下記2点に心当たりのある方に該当するかもしれません。

wp_optionsテーブルで「Got a packet bigger than ‘max_allowed_packet’ bytes」のエラーが発生したことのある方
SNS Count Cacheを使っている／使っていた方

状況確認

改善方法の前に状況の確認です。

過去に「Got a packet bigger than ‘max_allowed_packet’ bytes」が発生したことある方は、恐らくWP_OPTIONSが肥大化している可能性があります。

WP_OPTIONSはアクセスの度に読み込まれるため、肥大化するとパフォーマンスが著しく低下します。肥大化している場合、まず間違いなくテーブルに余計なレコードや不適切なレコードが格納されているので状況を確認します。

WordPressで使用しているテーブルのデータサイズは、WP-Optimizeなどのプラグインを使うと簡単に確認できます。私の環境では、wp_optionsテーブルのデータサイズは約110MBです。

レコードが貯まっていると1GBを超えることがあります。データサイズが大きい場合には、何か不具合が発生している可能性があるので対処が必要だと思います。

wp_optionsテーブルのデータサイズが大きい場合、不要なレコード、不適切なレコードがないか確認します。

select option_name, char_length(option_value) as length from wp_options order by length;

コマンドを実行すると、option_name、option_valueの文字数の一覧が文字数の昇順に表示されます。

問題となるのは、主に次の2つです。

option_nameに同じ文字列から始まるレコードが数百レコードもあれば、それは問題となるレコードです。また、極端に文字数が多いレコードも問題があります。

私の環境では、option_name=’cron’が原因でした。

cronは、WordPressのcronジョブが格納されているレコードなのですが、これにSNS Count Cacheのジョブが数万件も格納されており、option_valueが肥大化し、max_allowed_packetの上限値を大きく超え、MySQLのエラー原因となったようです。

SNS Cout Cacheは、かなり前にカウントされなくなったのでアンインストールしたのですが、こんな爆弾を残していってくれたようです。

cronジョブは、Advanced Cron Managerなどのプラグインを使えば個別に削除できます。

私は個別に削除するのが面倒だったのでcronレコード自体を削除してしまいました。削除後にwp_cron.phpを手動で実行したらcronレコードが作成され、cronジョブは実行されたみたいなんですが、真似はしないでください。

wp_optionsの不要なレコード、cronレコードの削除などをした結果、サーバ負荷はかなり改善しました。サクサクという程ではありませんが、管理サイトの重さを意識することはなくなりました。

いつからかMySQLがwp_optionsのクエリ処理中に最初に挙げたエラーメッセージを度々出力するようになっていましたが、当初は疑問を持たず、max_allowed_packetの値を8M→32Mと増やしてエラーを解消させていました。

今にして思えばこれが勘違いで、wp_optionsに8Mを超える文字数が格納されていることをもっと疑問視するべきでした。

WordPressが重い原因は環境により様々だと思いますが、症状改善の一助になれば幸いです。

参考にしたサイト