Posts」ですが、よく「動作が重い!」と話題になっていますね。僕が仕事でサーバ状態を監視しているサイト(注:このサイトではありません)でもそういったことはよくあるのですが、正直なぜそんなことになるのかよく分かっていませんでした。今回、そのサイトでおきた事件をきっかけに原因を分析してみましたので、ご参考になればと思います。僕のこのサイトと話が混在するとややこしいので、事件が起こったサイトを『サイトB』とします。後日談サイトBにて事件発生ある日の夕方、サイトBの動作がとても重くなりました。トップページにいたっては、上部のサイトロゴしか表示されない有様に。F5キーを押して更新したところ、サイト全体が以下のようなメッセージで埋め尽くされました。◇◇◇◇いまサイトの情報等は別の文字に置き換えていますが、実際にはデータベース構造が剥き出しになっていました^^;このメッセージは、『データベースからの情報取得に負荷がかかっているぞ!』という意味です。このためサイトBのデータベース監視ツールを確認したところ、CPU負荷が100%に!えらいこっちゃです。以下が、CPU使用率の画像です。(赤枠の時間帯に、異常に気付きました^^;)サイトBの環境サーバ環境として、AWSを利用しています。CPU負荷等の画像は、そのサービスのRDSを監視したものです。MySQL』を採用しています。Services)の略称です。Service)の略称です。データベースは、サイト運営のために記事等のデータを保管している倉庫と考えていただいて構いません。ややこしい話もいっぱいあるので、ここではあまり深く触れずに進めます。結論から述べると、集計データが【1ページビューごとにデータベースへ登録されるている】ことが原因です。通常は各記事ごとに1日1回ページビュー数を集計してデータベースへ登録していたはずなんですが、ある日を境に登録状況が変わっていました。以下画像は、このプラグインが使っている【どのページが何回見られたか】という数値を保管しておく場所(テーブル)の登録履歴から、1件の記事だけに絞ってみたものです。補足しておくと、postid:記事のIDpageviews:ページビュー数view_date:ページが見られた日view_datetime:そのデータを登録した日時です。登録日時を見てみると、連続して登録(書き込み)されているのが分かります^^;基本的に、データベースへの読み込み回数や書き込み回数は少ないほうが負荷は下がり、多くなれば上がります。この登録履歴を確認すると、サイトBに関しては2017年10月12日の10時58分ごろまでは、それほど負荷は無かったのだと考えられます。この日付以前は、1日1回の登録履歴しか残っていませんでした。(他の記事もほぼ同じ時間から変化しています。)なぜその時間から変わった?これは推測ですが、以下のうちいずれか、または全てがあったと考えるのが妥当かと思います。・負荷が始まった時間付近で、プラグインのアップデートを実施した・WordPressバージョンのアップデートを実施した・当該プラグインの何らかの設定変更を行なった僕はサイトBを管理したり記事を投稿したりしているわけではないので、こればかりは特定できません。管理者にも確認してみましたが、覚えていないということでした。(そりゃそうですよね。)原因になぜ気付いたかデータベース内のテーブルについて、まずはレコード数(行数)の多いものから確認してみようと考えました。その結果が以下の画像です。『wp_popularpostssummary』というテーブルは、人気記事一覧の情報を格納するところです。・・・ええ~っと、25万行?笑このテーブルを数ヶ月前に確認したときは、3万行程度でした。これは異常だと思いテーブルの中身を確認した結果、例の1ページビューごとに。いう原因を発見したということです。運よく、一発で原因を発見できました☆笑スポンサーリンクスポンサーリンク今回とった対策1.サーバ(RDS等)を再起動ワードプレスの管理画面すら開けない(例のエラーメッセージでいっぱい)という状態だったので、まずはサーバ関係を全て再起動しました。Posts」を停止しました。それ以外のものは設定も触らずに、ひとまず原因を特定させようとしました。結果サーバへのアクセス状況は減り、ページも速やかに表示できるようになりました。今回話題には挙げませんでしたが、一応CPUクレジット残高の状況も載せておきます。CPUクレジットを使ってCPUの使用域をバーストさせることが出来る契約をしています。CPUクレジット残高ぎりぎりの状態で再起動をかけました。(汗)一日中アクセスがあるホームページに関しては、こういったタイプの契約は合っていないのでは?という勉強にもなりました。ちなみに数日後に突然クレジットが全回復していますが、原因は調べてません。他で管理しているRDSでも同様の回復があったので、AWS全体の話だという理解でとどめてます。発見が遅れたことの原因として、定期的な監視をしていなかったことが挙げられます。定期的な監視をしていることで異常兆候をつかみやすくなりますし、普段の状態というものを知ることが出来ます。普段の状態がどうなのかを理解していないと、不具合発生時に原因の特定が遅れてしまいます。ホームページの動作が遅いという事象1つに関しても原因はひとつとは限らないので、CPU使用率やデータベースへのアクセス回数などを見渡して、瞬時に見つける必要があります。「普段のCPU使用率は20%以下なのに今日は50%を超えている。おかしいぞ!」などですね。いったことを踏まえて、今後は定期的な監視をしていきます^^その他の対策こちらのブログで紹介されているように、プラグインの設定見直しが必要な可能性もあります。何日分のログを残しておくか?ということも考えるべきでしょう。実は数日前から、再びこのプラグインを復活させて様子を見ています。いまのところCPUクレジットに急激な減少はありませんが、やはりアクセスが集中すると結構負荷がかかりCPUの使用率は上昇しています。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。【2017年10月末~11月上旬】モルディブの気候はどうだった?2017年11月18日SEメモ次の記事プリントパックとラクスル。電話が繋がらないのはどっち?2018年1月10日スポンサーリンク検索:人気記事一覧プリントパックで発注!結婚式プロフィールブックの作...Inkscapeでトンボ(プリントマーク)を設定!...無線キーボートのcとhが効かなくなる。これって何の...プリントパックとラクスル。HazamaLife。