このサイトでは、wpXのレンタルサーバーを使っていますが、ある日「お客様のサーバーアカウントにおける著しく高いCPU負荷について」という重要メールが届きました。このサイトのせいで、一時的に高いCPU負荷がかかっていたので、アクセス制限をかけていたとのこと。今後も同様のことが起こるなら、個別のリソース制限を設ける可能性があるという不穏なお知らせ。お客様のサーバーアカウントにおいて、CPU負荷が著しく高い状況が確認されましたのでお知らせいたします。そのため、お客様のサーバーアカウントへのWebアクセスを一時的に制限しておりました。現在はWebアクセスの制限を解除しております。事後のご連絡となり大変申し訳ございませんが、何卒ご理解くださいますようお願いいたします。今後も同様のCPU負荷が継続する場合、お客様のサーバーアカウントに対して個別のリソース制限を設ける可能性がございます。お手数ですが、お客様が運用中のWordPressにおいて、CPU負荷への対策を行っていただきますようお願いいたします。管理パネルにログインして、「サーバー管理」→「サーバー設定」→「サーバー情報」から調べてみると、、なんとCPU使用量と転送量がどちらも激しく真っ赤な状態に。通常は100%以内が目安のところ、連日のように数百%もの数値を叩き出している始末でした。今まで制限がかけられなかったことをwpXに感謝しないといけないくらい。うちのサイトの規模からすると、wpXクラウドでなくとも、レンタルサーバーのプランで大丈夫だと思っていたので唖然としました。理由がまったく不明だったのですが、ネットで対策を探りつつ、サーバー負荷(CPU使用量と転送量)を軽減するために、10の方法を試してみました。Dayのゴミを消す1.PHP7.0へ移行wpXからのメールには、最新のPHP7.0を試してみるようにとの提案が。なんでも「PHP5に比べ2倍以上の性能向上や大幅なメモリ使用量の改善が行われたPHPの最新バージョン」なのだとか。切り替えは管理パネルの「サーバー設定」→「PHPバージョン切り替え」からできますが、試してみた所、運営している両サイトともに、エラーになってサイトが表示されなくなってしまいました。Excluderが引っかかっていらしい。これは、カテゴリ別に表示・非表示を切り替えるプラグインで、主旨と外れた記事をメインインデックスやRSSフィードから除くのに使っていました。最終更新は3年前になっているので、PHP7.0への対応は期待できそうにない。Excluderでやっていたことを、テーマの編集で代用できることが判明。こちらの記事の提案にそって、子テーマのindex.phpやarchive.phpを編集して、特定のカテゴリの投稿を除外。自分で何とかスルBLOG次にこちらの記事の提案にそって、子テーマのfunction.phpに追記して、RSSフィードからも、それらのカテゴリを除外。Excluderでやっていたことを代用できたので、プラグインを無効化。晴れてPHP7.0に移行することができ、エラーもなくブログが表示されるようになりました。次に、多くの人が使っているであろう多機能プラグインJetpackの機能の一つ画像の読み込み負担を軽くしてくれるPhotonを有効化。画質が低下する、キャッシュが削除できないなどのデメリットがあるようですが、うちのサイトは写真メインではないので、大丈夫だろうと。このサイトよりも、サブのもう一つのサイトのほうが画像が多いので、そちらのほうでより効果が見込めるかな、と思いました。Captureという便利なサービスを使って、サムネイル付きで表示していました。HeartRailsを使うと、外部のHeartRailsのサーバーからサムネイル画像を引っ張ってきているようで、HeartRailsのサーバーが重いときは読み込み不良が生じてしまっていました。記事の見た目が損なわれる上に、読み込みも全然終わらなかったり。したらこれもCPU負荷の一因か?と思って、思い切って、HeartRailsを使っていたリンクを全部貼り替えることにしました。WordPressの投稿一覧の検索ボックスの欄に、「HeartRails」と入れると、リンクにHeartRailsを使っている記事一覧が出てくるので、一つずつ手動でサムネイルを消していくという気の遠くなるような作業。外部リンクはサムネイルを消すだけ、内部リンクはfunction.phpをいじって、ショートコードでブログカード風のリンクが作れるようにしました。これでどちらも外部サイトからの読み込みはなくなったはず。全部で700記事くらいあったのですが、過去の記事の修正、見直しもかねて、数日かけて終わらせました。効果があるかどうかはともかく、ブログの見た目はとてもよくなりました。安易に外のサーバーから画像を引っ張ってくるようなサービスに手を出すと、Amazonなどのように外のサーバーがよほど強くないかぎり、サーバーダウンしたら自サイトも影響されますし、最悪サービス終了したら画像が表示されなくなってしまうのだ、ということを実感するよい機会になりました。Thumbnailsを使って整理しました。このプラグインを使うときはさきほどのPhotonを一時的に無効化しておいたほうがいいのかも。使って画像を整理することのススメ、環境によっては画像ファイルが半分に。整理する前に、WordPressの投稿一覧の検索ボックスで「medium」「large」「thumbnail」」で検索して、サイズ選択して載せている画像があればフルサイズに差し替えるのを忘れずに。経験知?4.負荷をかけているプラグインを調べるそこそこプラグインは減らしてきたつもりですが、調べてみると、負荷が高いことで有名なプラグインを幾つか使っていることが判明。Pack(SEO関係の一括設定)など。Profiler)というプラグインで調べることができます。SEOはとても便利で多機能なので、使わざるを得ないかな、という具合ですが、ほかのものは消せるかもしれない。SEOも改めて設定を見直して、使わない機能は根こそぎオフにしておきました。Checkerをやめる上記のプラグインのうち、いずれも、それぞれのプラグインの設定画面で、負荷軽減を試みることができます。Checkerは、設定画面の「高度な設定」を見ると、「サーバー負荷の制限」、「ログの保存」などの項目があり、この部分で制限をかけたり、ログを削除したりすれば、少しは軽くなるようです。常にリンク切れを監視してることがそもそも負荷が大きいですし、最近のSEOの情報を見ていると、リンク切れが多数あっても、Googleの評価には影響しないらしい。(#SEMR)読む人の利便性が下がるせいで間接的に評価が下がることはありそうですが、うちは自前の記事の内容を充実させているので、そこまで気にする必要はないかなと。Checkerは無効化することに。Posts)をやめる記事の終わりなどに、関連記事のリストを出力してくれるYARPPは、関連記事系のプラグインの中でも特に使い勝手がよく重宝していました。細かく分析して、関連記事を探し出す、という高度な機能が仇となるのか、負荷もまた大きいという問題点が。最初はあらゆる記事の中から、関連度の高い記事を探してもらっていたのでYARPPが必須だったのですが、このサイトではGoogleの関連コンテンツ機能を使えるようになったので、YARPPの機能を代用できるようになりました。その後は、Googleの関連コンテンツ機能でできない、同じカテゴリの記事を出力するためにYARPPを使っていましたが、調べてみると、その程度のことはプラグインなしでできることが判明。プラグインなし」あたりで検索すれば、やり方を説明したサイトがたくさんヒットするので、YARPPも無効化して、プラグインなしの方法で代用することができました。うちではこちらの記事を参考にさせていただきました。アフィリエイトで稼ぐ方法を全部話そうと思うYARPPと違って、この方法だと、カテゴリーが同じであれば関連性が高いか低いかに関わらず表示されてしまうという欠点もあるにはあります。複数のカテゴリーに登録している場合は、雑多な関連記事になることも。それで、この機会に、複雑化していたカテゴリー分けを整理し、いらないカテゴリをまとめて消去しました。内容に関係なく、雑多な記事を登録していたカテゴリ(「今年のニュース」とか「読んだ本の感想」など)は、そのままだと一見、全然関係なさそうな記事が関連記事に出てきてしまうっていました。そこで、カテゴリではなくタグにすることで、関連記事に表示されないようにしつつ、「今年のニュース」や「読んだ本の感想」はタグアーカイブのほうで一覧できるようにしました。こちらも、常に人気記事のログをとっているわけなので、重いのはあたりまえです。先ほどのものと動揺、こちらも設定を見直すことで、軽くすることが可能。cache」ボタンがあるので、全期間のデータは保持したまま、細かいキャッシュデータを削除できます。Policy」という項目をEnabled(有効)にすると、キャッシュを特定の期間ごとに自動で削除できるよう設定できます。Sampling」の項目を100→10くらいにすれば、100人のユーザーの動向をそのまま計測するのではなく、100人中10人だけをサンプルとして選んでデータを集めるようになるので、負荷が軽減されます。...このサイトでは、人気記事の計測は、Jetpackでもすでにやっていること。Postsを使い続けていました。Viewsというプラグインが、Jetpackのほうの統計情報を参照しながら、人気記事を件数もカテゴリも自由に出力できることが判明。Postsの代わりに設置。Postsに比べるとカスタマイズ性が少し弱いですが、調べてみると、愛好者もけっこういるようで、カスタマイズの情報もちらほらありました。少なくとも、このサイトでは十分。Viewsのほうはショートコードの記載の仕方がわからず、できなかったこと。Pagesというプラグインで、ウィジェットをショートコード化して固定ページに貼り付けられることがわかったので無事に解決。SiteOriginという似た機能の有名プラグインもありますが、なぜかうまくいかず)プラグイン数は増えたものの、常に統計情報を監視しているプラグインをJetpackのみに統一できたので、全体の負荷は下がったはずです。お願いしたいところです。Jetpackというプラグインもありました。ワドプラプラグインに頼らずに自力で実装できる方法を書いてくださっている方もいたので、時間のあるときに試してみようかなと思います。Analyticsの統計を引っ張ってくる人気記事プラグインもありました。設定がかなりめんどくさいのがハードル高いです。Galleryも、CPUに負荷をかける系統だということが発覚。代表的な負荷の大きいプラグインで、データベースのwp_optionsの中にも名前が出てきていました。Galleryを使うしかなかったのですが、今ではWordPressそのもののギャラリー機能もパワーアップしていますし、外部サイトを埋め込むなどの方法もあります。Jetpackの機能の中にある、「タイルギャラリー」がとても優秀。Gallery並みかそれ以上のオシャレなギャラリーにできます。Jetpackの「タイルギャラリー」を有効化するにあたり、タイルギャラリーの画像を見栄え良く表示できる「カルーセル」も有効化。lightBoxを無効化。ライトボックス系プラグインは、画像をクリックしたとき、別ページに移動するのではなく、そのページのままポップアップウィンドウで拡大表示してくれて、見栄えをよくしてくれる便利なプラグインなので、これまで愛用していました。ライトボックス系プラグインはそれなりに負荷があるので、ないに越したことはありません。考えてみれば、今はスマホビューがブログ訪問者の半数以上を占める時代。スマホの小さな画面でポップアップして拡大表示してもサイズなんて変わりません。それにうちのブログの画像は縮小してあるので、画面が大きくてもたいして拡大表示にはならない。スマートデバイスでは、ピンチイン・ピンチアウトで拡大・縮小できるので、画像を触ったら、ポップアップしてしまうライトボックス系機能はユーザーにとって邪魔だともいえます。ライトボックス系プラグインを無効化しただけでは、画像に触れると別ページに飛ばされるという、よりユーザビリティの悪いサイトになってしまうので、以下のの記事の情報に従って、画像を触ったら画像のページを開くというリンクそのものをなくしてしまいました。記事にも書かれていますが、時代の変化でしょうね。モバイル全盛の今となっては過去の遺物な気がします。画像のリンクを一括で無効化しても、Amazonなどの画像のリンクはなくなりませんし、Homeにリンクしているヘッダー画像や、自分でリンク先を指定しているプロフィール画像などのリンクは無効化されないので安心です。してもリッチな見栄えのいい表示をしたい画像は、前述のJetpackのタイルギャラリー&カルーセルを使えばいいだけなので、すべての画像でライトボックスをなくすのはちょっと...という場合でも問題ありません。不必要な機能を削っただけですね。今回、いろいろとプラグインを消しましたが、Jetpackで代用できる機能が多くてとても助かりました。Jetpack自体もCPU負荷は大きいですが、外せない機能が多いので、一元化してまとめるだけでもかなり違うはずです。9.データベース掃除のプラグインここまでで、それなりに負荷は削減できたはずで、数百%にもなっていた負荷が、200%くらいにまで落ち着きました。それでも許容量の2倍なのですが...。ほかにできることはないか探していると、ちょっと目を疑ってしまうものが。wpXの「WordPress一覧・設定」を見ると、管理している2つのブログ両方で、DB(データベース)容量が、既定値の500MBを大きくオーバーして、800MBとか使用してしまっていました...。今まで警告がこなかったことがこちらも不思議なほど。WordPressには、DB容量と、ディスク容量の二種類の容量がありますが、ディスク容量のほうは、全然余裕たっぷりでした。画像ファイルなどの容量ではなく、データベースのMySQLの容量がパンパンだということ。こちらの記事によると、データベースを整理できるプラグインが幾つかあるとのことで、バックアップをエクスポートした上で色々と試してみました。ネタワンまずはWP-Optimizeで、リビジョン削除、データベース最適化など。この際、古いコメントやトラックバックなどもスパムと一緒に消してしまいました。このサイトがコメントを開けていたのは初期の一時期だけなので、もう必要ありません。古いプラグインが使っていたゴミ化したデータを捨てるプラグイン。プラグインをとっかえひっかえあれこれ試している人ほどゴミが多いはず。調べてみると、少しだけ捨てられるものがありました。これは、MySQL内の各種設定データwp_optionsの中から、いらなさそうなものをピックアップして捨てられるプラグイン。このwp_optionsは下手にいじると危ないのですが、膨大なゴミも溜まりやすいやっかいなところ。調べてみると両ブログともに400件ほどのゴミらしきものが。データベース名を見ると、Jetpackのデータなど、ゴミでないものも大量に含まれているようなので、もう使っていないプラグインの名前がついているものだけを捨てていきます。Dayのゴミを消すこの一連の作業の中で、何度か見覚えのある名前が。Day」という名前のついたデータベースが引っかかる。Dayは、無料ブログなどによくあるアクセスカウンターを設置するプラグインですが、WordPressではなぜかアクセスカウンター機能がないので、ずっと使い続けていた時期がありました。Dayは、以前の記事で書いたように、計測が全然正確でなく、設置しておく意味がわからないくらい適当。Postsばりに統計情報も集めているという変なプラグイン。信頼できなかったので消したはいいものの、これが収集していた統計情報のデータがデータベース内にかなり残っていたらしい。Options中からは消せず、わざわざサーバーからMySQLのほうにログインして消しました。その後でデータベース容量を確かめると...無事適正値に!下のサイトのほうなんか、1/10の容量になっていて驚きました...。Dayのゴミだったのでは...。Jetpackの統計情報の容量は大丈夫なのか気になっていましたが、両方のサイトで使っていて、下のサイトのほうが統計情報が多いはずなので、たぶん大丈夫なのでしょう。やればできるもんなんですね...。何も知らずにサーバーに負荷をかけまくっていて本当に申し訳なかったです。サイトを整理するいい機会になりました。今のうちに、wpXレンタルサーバーからwpXクラウドのほうに移行しておいたほうがいいのか...ということも含めて悩ましいところですが、ひとまず危機は脱したのではないかと思います。記事の更新を選択的に通知する。