ワードプレスが急に重くなった時の調査フローと、一時キャッシュ(Trasient Cache)の削除方法

  • ブックマーク
  • -
    コピー
KUSANAGI 環境で弊社がホスティングしているWebメディアへダッシュボードも一般公開ページもアクセスしにくい状況発生しました。その後に Jetpack 経由でサイトがダウン通知が届いたので状況を把握することはできたので、その後にどのような手順をおって解決したかを解説します。 結論は、今回の僕の状況ではAMPプラグインのエラーをDBの一時キャッシュ(Trasient Cache)として保存しており、よってDBが肥大化し公開しているページやダッシュボードにつながりにくくなったという状況でした。 まずはサイトダウンしたことを知るところからはじまります。現在利用しているホスティング会社のサービスなどを利用して、サイトダウンの通知をうけるのもいいですし社内にインフラエンジニアさんがいてセルフホスティングしている場合も同様にサイトがダウンした通知を受ける導線を確保しましょう。 前述の方法が難しい場合は Automattic社 の Jetpack というプラグインを利用すると簡単にダウンしたときと復帰した時の通知をメールで受け取ることができます。
WordPress がダウンした時の通知メール
WordPress が復帰した時の通知メール
このように WordPress.com に登録し Jetpack 連携することで、サイトをモニターして異変が起きたときには通知をしてくれます。 通知が来た時に問題が一時的なもの、もしくは継続的なものかを判断します。今回は復帰した後もサイト自体にアクセスしようとするとローディングが途中で終わり表示されなかったり、表示されても数十秒以上続くという状態でした。 ここで考えられる問題は、多くの場合は下記のどちらかです。
  1. ハッキングもしくは攻撃されている
  2. 潜在的な問題が顕在化した
この問題を見つけることが特定と修復の第一歩なので、まずはダウンする寸前に誰かがなにかしたかということを明確にしなければいけません。 Jetpack にもアクティビティ機能がありますが、無料では制限があるため予算があわなければ プラグインの Simple History を利用するとよいでしょう。
Simple Historyの管理画面のスクリーンショット
前述のとおり、サイトダウンが発生した時に誰が何をしていたかを特定すればなにかヒントがあるので、その問題を潰すことができます。例えば特定の記事に画像をアップロードした、特定の設定をおこなったもしくは変更した、などお使いの WordPress のすべてのユーザの行動履歴を追えるため「なにもしてないのに止まった」というあるあるの証言を回避することもできます。 今回の僕の事例では新たに記事を投稿してからサイトがダウンしたため、投稿をしたことをフックになにかしらが起きたということが想定できます。 次に確認したのがサーバのエラーログです。 KUSANAGIの場合は配置(プロビジョニング)された各サイトの直下にlogディレクトリがあるのでその中身を確認し、特定の時間に何がおきたのかをさらに詳しく見ていきます。
KUSANAGIで困っと時の解決手引
それ以外の環境でもホスティングサービスによってはコントロールパネルでエラーログが見れるものもあるため、原因の特定をするためにエラーログからヒントを探すと良いでしょう。 また問題の原因がわかってもすぐに修正せずにいつでも現状に戻れるようにデータベースと公開ディレクトリのすべてのファイル(特にwp-contentの中はすべて)のバックアップをとっておきましょう。 KUSANAGIの場合はすでにコマンドラインから WordPress を操作できるツール WP-CLI がインストールされているため下記のコードでDBのバックアップファイルを作成することができます。

wp db export

WP-CLI のDBをエクスポートファイルを生成するコマンドの詳細
バックアップが完了したら原因と思われるところの対応をすすめていきましょう。 前述のとおり、今回はAMPプラグインが生成した一時キャッシュによりDBが肥大化してしまい2.1GBになっていたので、不要な列を削除することによって解決しました。
WordPress データベースの肥大化を解消するための記事
また、wp db export をする前に一度データベースのサイズを見ておくとDB内の問題かどうかもわかるので下記のコマンドを実行して確認するとよいでしょう。

wp db size --tables

WP-CLI のDBを見るためのコマンドの詳細
次に肥大化している箇所を発見したら中身を確認し、不要なDBの列を削除していきます。今回の場合は下記のようにwp_optionsが2GBをこえる状態だったので中を見て該当の項目を削除しました。
wp db size –tables の表示
一時キャッシュの列を手動で消していくのも大変なので WP-CLI にあるwp transient を利用して一括で削除していきます。
WP-CLI で一時キャッシュを削除するコマンドの詳細

wp transient delete --all

上記の結果、DBは通常のサイズに戻りサイトのレスポンスも正常に戻りました。
  • ブックマーク
  • -
    コピー

この記事を書いた人

Susumu Seino

1988年 東京都足立区生まれ。瀬戸内海の小島と東京に拠点を持ち、2020年からは夫婦でアドレスホッピングを計画しているデジタルノマドな日本人。デジタルパブリッシング代理店のアニューマの創業者です。