世界中のホームページの50%以上で使われているというWordPress。先日、管理しているサイトのデータベースが6GB超という事態に出会しました。

ホームページにアクセスすると、症状としては

• 503エラーで表示不能。
• 表示するが極端に遅い。
• 500エラーで表示不能。

を繰り返しました。

テンプレート修正等は行っていないため、当初はアップデート等による不具合・DDoS攻撃等を疑いましたが、プロバイダからの通知でデータベースが6GB超と極端に肥大していることが判明しました。

wp_optionsとは

wp_optionsテーブルをスリム化すれば良いだろうという想定はすぐにつきましたが、wp_optionsに入っている内容が分からないと手の打ちようがありません。

phpMyAdminで覗いてみると、pochilog.jpのデータベースではこんな内容です。

サイトのURLや名前等の基本情報が詰まっていますね。

しかし後ろの方を見ると

jetpack関連、widget関連、そして目立つのがoption_name列に「_transient_****」という項目です。なんだこいつら？「wp_options　内容」等のキーワードで検索しても、wp_optionsには何が格納されるのか？の詳しい解説は出てきませんでした。

http://wpdocs.osdn.jp/データベース構造#.E3.83.86.E3.83.BC.E3.83.96.E3.83.AB.EF.BC.9A_wp_options

http://wordpress.nakweb.com/blog/hello-world/

まずはプラグインで対策

https://www.amamoba.com/wordpress/clean-options.html

調べてみると「Clean Options」というプラグインがよく出てきます。「使っていないテーブルを削除してくれる」とありますが、削除対象選択の最終判断は使用者に委ねられているようで、なかなかハードルの高いプラグインです。さらにこれ、7年前にアップデートが停止しています。

しかし背に腹は替えられない！

エイヤッと使ってみましたが、ほとんど効果がありませんでした。そりゃそうだ、使っていないテーブルは削除してくれるけれど、wp_options内の不要なレコードを削除してくれるわけじゃないですから。

とにかく総当たりで検索

phpMyAdminでwp_optionsテーブルを選択し、とにかく目につくキーワードを片っ端から検索してみました。

例：

• SELECT * FROM `wp_options` WHERE option_name like ‘%_transient%’
• SELECT * FROM `wp_options` WHERE option_name like ‘%jpsq_sync%’

げ。

「_transient」で検索した結果が約1000行。これは一時的なレコードにつく名前で、時間がたてば消去されるべきものとのとこです。

http://ameblo.jp/kagemushabusiness/entry-11591398893.html

• まずはデータベースをバックアップして万が一に備えます。
• SELECT * FROM `wp_options` WHERE option_name like ‘%_transient%’で検索結果として表示されるものを100件ずつ表示して「全てにチェック」して削除します。

10回ほど繰り返してきれいさっぱり！6GBあった容量が5.98GBぐらい・・雀の涙(T_T

次に「jpsq_sync」で検索した結果が1600万行！

https://wordpress.org/support/topic/jetpack-sync-killing-the-db/

日本語のサイトは見つかりませんでしたが「jetpack-syncがデータベースを殺す！」という物騒な記事を見つけました。便利なjetpack、多機能だけどこんな手落ちが！？

これはSELECTで検索して順次消去・・・ってやってたら何ヶ月かかるか分かりません。

• DELETE FROM `wp_options` WHERE option_name like ‘%jpsq_sync%’

かなり乱暴ですが、いざとんればバックアップもあるし、一から設定し直すことになってもその方がマシだろうと実行しました。実行には1時間ほどかかりました。

結果、6.4GB→114MBに！

• jetpackの連携が切れる。
• パフセリサイズ共有の連携が切れる。
• プラグインの寄付メッセージが再び表示されるようになる。
• TinyMCE Advancedの<P>タグ保持設定が無くなる。

等の問題がありましたが、最大の問題は解決しました。

Jetpackはヤバいのか？

引き続き調査中というか経緯を見守らないと分かりませんが、これまでのアップデートに不具合のあるバージョンがあったのかもしれません。

念のため

http://ameblo.jp/kagemushabusiness/entry-11593112832.html

自動で「_transient」レコードを消去してくれるプラグインに関する説明です。問題が再発するようなら、これを改造して「jpsq_sync」も消してみようかしら？

ぜひ一度、wp_optionsのテーブルサイズを確認してみてください。「WP-DBManager」等のプラグインでかんたんに確認できます。

間違い・その他情報等ありましたらぜひコメントいただけるとありがたいです。