ワードプレスドクターのお客様の中には月間数百万から数千万PVを誇るメディアサイト様がいらっしゃいます。アクセス数が非常に多いサイト様ですと統計関連のプラグインなどに一般的には表れない不具合が顕著となる事がございます。今回はこのクライアント様のご依頼事例から管理画面が非常に重くなってしまっていた問題のご解決事例を2点ご紹介します。
この記事の目次
事例１ ワードプレスの管理画面だけが非常に動作が重くなっていて更新もままならない状況に
こちらのお客様はゲーム関連の、非常にアクセス数の多いサイトを管理されている方で、サーバーの移転後に管理画面が急速に重くなり、ついには更新すらままならないほど、動作が重くなってしまったというご相談でした。
クライアント様の症状
・サイトは普通に閲覧できるが、ログインすると20秒から30秒ほど管理画面でのページ遷移の時間がかかる。または５０３エラーによる過負荷エラーが頻繁に発生する
・サーバーのエラーログに、 PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4420840 bytes) in /xxxx/wp-includes/wp-db.php on line 1978
とメモリエラーが発生
・PHPのメモリ使用上限を引き上げても状況は改善せず
・予約投稿等もなぜかできない
といった状態でございました。
管理画面が重い理由と対処方法
サイト自体はちゃん高速に表示されるのに、なぜ管理画面だけが重い状態になっていたかと申しますと、実はサイト全体が重いにもかかわらず、キャッシュプラグインによって幸運なことに非ログイン状態のときはそのキャッシュが表示されていたことからサイトが重くなかったことがわかりました。
また、
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4420840 bytes) in /xxxx/wp-includes/wp-db.php on line 1978
は、データベースと通信するワードプレスのプログラムですのでデータベースを調査しましたところ、テーブル wp_options ＞ cronというテーブルに超巨大なデータが書き込まれていることを発見いたしました。
このテーブルは、ワードプレスの自動実行処理をつかさどるテーブルです。
何らかのプラグインが暴走して巨大なデータを誤って作成している可能性が高く、調べたところ下記のようなパターンで大量のデータが書き込まれ続けていることがわかりました。
scc_share_restorecache_exec .... scc_share_lazycache_exec ....
このデータは、プラグインSNS Count Cacheによるものですので、さらにプログラムの流れを調べたところ、ユーザーがアクセスするたびになぜかcronの自動実行ジョブを一つ書き込んでいることが判明いたしました。
つまり1時間に数万件のアクセスがあるサイト様では、一つのテーブルに一日で数十万件のデータが無意味に書きこまれ続けていることになります。
プラグイン自体のバグを修正すると、工期と料金が大きくなってしまうことから
このプラグインのすべてのCRON書き込み処理命令をいったん停止させて(※ プラグインの自動キャッシュ取得機能が利用不可能となりますがプラグイン自体は継続利用可能な状態です。)、データベースのテーブルの破損を復元することによって管理画面が重くなる問題をご解決させていただきました。
CRON書き込み処理命令は、プラグインで利用されているワードプレスの関数の下記のような部分となります。
wp_schedule_single_event(スケジュールの内容);
事例２ データベースの容量が２００ギガに肥大化、またワードプレスの管理画面とサイトが非常に動作が重くなる
こちらのお客様の事例では、まず、サーバー会社からデータベースが容量制限を超えて２００ギガバイトまで大きくなっているためにすぐに無用なデータを削除してほしい旨通告されて、データを削除されても容量はほとんど減らず、また管理画面やサイトの表示も非常に重くなってしまっているとのご相談でした。
データベース肥大化の原因
データベースをお調べしましたところ、まず、下記のようなデータがWP-OPTIONSテーブルに大量に書き込まれていることを発見しました。
_transient_xxxxx
このデータは、プラグインなどが最後に処理した時間を一時保存しているもので削除しても問題が無いことが多いです。これにより数千万件のデータが削除できました。
しかし、このデータを削除してもデータベースの容量は2割ほどしか低下しないことがわかりました。
巨大化しているデータの主な部分は、データベースのINDEXと呼ばれる、実データではなくデータの検索を高速にするための牽引(INDEXと呼ばれます)の部分であることがわかり、さらに調査すると、WP-Security-Audit-Logというプラグインがサイトのアクセスの度に４０４エラーをいったん書き込んでは消してという処理を繰り返していることが判明しました。
このことにより、実データは増えていないのに、牽引であるINDEXデータだけが巨大化していたのです。
※下図はAdminerというデータベース編集ツールで実データではないINDEXデータのサイズを表示している図です。
このプラグインの使用を一旦停止し、INDEXデータを最適化することでデータベースの容量は数百分の１に低下し、管理画面やサイトの表示速度も劇的に改善することができました。
データベースのテーブルのINDEXデータを最適化(消去)するには下記のようなコマンドを発行します。
(データベースに何らかの変更を加える場合は必ずバックアップをお取りになる事をお勧めいたします)
ALTER TABLE wp_options
