WP-CLIをつかったWordPressの健康診断方法まとめ

WP-CLIを使用するとWordPressの管理画面だけではできないいろいろな健康診断を行うことができます。

コアが改ざんされていないかをチェックする

wp checksum core というコマンドを使用すると、WordPress本体が改ざんされていないかをチェックすることができます。

$ wp checksum core 
Success: WordPress install verifies against checksums.

以下は、wp-settings.php というファイルを書き換えた後のコマンドの実行結果のサンプルです。

$ wp checksum core 
Warning: File doesn't verify against checksum: wp-settings.php
Error: WordPress install doesn't verify against checksums.

残念ながら、日本語版ではWordPressのアップデート直後に readme.html が書き換えられてんぞーとエラーが出てしまう不具合が発生することがありますが、現在対処方法を検討中です。

データベースのサイズを確認する

本体の問題では聞いたことがありませんが、サードパーティのプラグインの不具合によりある特定のテーブルが異常に肥大化することが原因で、WordPressのパフォーマンスが低下することがあります。

その場合は、wp db size --tables コマンドを実行して極端に大きなテーブルが無いかを確認してみるといいかもしれません。

$ wp db size --tables 
+-----------------------+----------+
| Name                  | Size     |
+-----------------------+----------+
| wp_users              | 8 KB     |
| wp_usermeta           | 20 KB    |
| wp_posts              | 12 MB    |
| wp_comments           | 409 KB   |
| wp_links              | 6 KB     |
| wp_options            | 616 KB   |
| wp_postmeta           | 2 MB     |
| wp_terms              | 31 KB    |
| wp_term_taxonomy      | 19 KB    |
| wp_term_relationships | 141 KB   |
| wp_termmeta           | 48 KB    |
| wp_commentmeta        | 1,015 KB |
+-----------------------+----------+

上のデータは、運用7年ぐらいで600件ぐらいの記事があるブログでこのコマンドを実行した結果です。

WP-CLIチームに過去に報告があった事例を見てみると、関連記事系のプラグインや超有名コメントスパム対策のプラグインはテーブルを肥大化させる傾向があるようです。

テーブル名の末尾が meta になってるテーブルのサイズが数百MBとかになってることがあるようなのでご注意。

対処方法はプラグインによって変わるのでなんとも。。。

メタデータを確認する

上述の *meta テーブルが極端に大きい場合に、wp post meta list などのコマンドでメタデータのリストを取得することができます。

• wp post meta list <post-id>
• wp comment meta list <comment-id>

Cronイベントを確認する

WordPressのコアのアップデートのチェックや予約投稿などは、Cron という仕組みによって保存されています。

これらは、プラグインの不具合（過去にはWordPress本体の不具合）により肥大化することがあり、その場合もパフォーマンスに大きな影響を与えます。

以下はインストールしたてのWordPressに登録されているCronのリストを wp cron event list というコマンドで取得した例です。

$ wp cron event list 
+-------------------+---------------------+-------------------+------------+
| hook              | next_run_gmt        | next_run_relative | recurrence |
+-------------------+---------------------+-------------------+------------+
| wp_version_check  | 2017-08-28 04:12:34 | now               | 12 hours   |
| wp_update_plugins | 2017-08-28 04:12:34 | now               | 12 hours   |
| wp_update_themes  | 2017-08-28 04:12:34 | now               | 12 hours   |
+-------------------+---------------------+-------------------+------------+

もしプラグインを強制的にすぐにアップデートしたいときは、これらのCronを強制的に実行することもできます。

$ wp cron event run --all 
Executed the cron event 'wp_version_check' in 2.783s.
Executed the cron event 'wp_update_plugins' in 0.524s.
Executed the cron event 'wp_update_themes' in 0.615s.
Success: Executed a total of 3 cron events.

プラグインに不具合がある場合、同じ項目が大量に登録されていたりしますのでたまにチェックしてみるといいと思います。

Optionの数を確認する

プラグインをたくさんインストールしすぎないでーってよく言われると思いますが、プラグインをたくさんインストールすることによるパフォーマンス低下の原因は、おもにOptionの肥大化によるものです。

WordPressは wp_options というテーブルに保存されているデータのほぼすべてを毎回読み込みますので、これが肥大化すればするほど多くのメモリを必要とします。

残念なことにプラグインをアンインストールしても、この問題は解消しませんので、本番環境でプラグインの動作試験をすることは避けましょう。

Optionの数をチェックするには wp option list --format=count というコマンドで見ることができます。

$ wp option list --format=count
565

これは僕の個人ブログでの実行結果の例です。

単純にこの数字だけでなく wp db size --table の結果とあわせてチェックしてみるといいです。

極端に多い場合、たとえば数万とかになると要注意です。

オブジェクトキャッシュ

これはかなりエンタープライズ向けの機能なので、一般のみなさんにはあまり関係ないかもしれませんが、オブジェクトキャッシュの内容をチェックすることもできます。

• wp cache *
• wp transient *

これらは、サードパーティのプラグイン等によって結果がかわるので、心当たりがある人は試してください。

その他

現在 WP-CLI チームではパフォーマンスのボトルネックを探るコマンドや、公式ディレクトリ上のプラグインの改ざんをチェックする方法などを検討しています。

それらについては、またでき次第報告します。