Xserverから高負荷アラートが来た。その2

先日、Xserverから高負荷アラートが来たという旨の記事を書きました。

 

その記事では、問題を解決させました旨を綴りましたが、あくまで個人的に解決させただけであって、実は解決できていませんでした。。。

 

結構大変な思いをしたので、ブログに残したいと思います。

 

そもそもの勘違い

前回の記事のとおり、YARPPを停止させ、その後2,3日様子を伺っていましたが、特にXserverから連絡がなかったので、「もう解決した」ものと思っていました。

 

ところが1週間後、

 

1/8にも同様のご連絡を行っておりますが、お客様がご契約中の上記サーバーアカウントにおいて、該当MySQLデータベースに対する著しい負荷上昇を確認いたしました。

 

「うーん、YARPPが原因じゃなかったのかな？」

と思ったのですが、メールを読み進めると、原因となるSQLが

 

▼問題と思われるSQL
——————————————————-
SELECT object_id, term_taxonomy_id FROM XXXXX_term_relationships INNER JOIN line_posts ON object_id =
——————————————————-

 

となっており、前回疑わしかったSQLとは異なるものでした。

 

さらに、前回のメールで見落としていたのですが、

 

大変お手数ではございますが、早急にデータベース負荷の軽減処理を行っていただきますようお願いいたします。

 

※データベース負荷対策を行っていただきましたら、必ずサポートまでご連絡くださいませ。

 

ご連絡をいただきましたら、当サポートにて対応策の内容を確認し段階的な制限の緩和・解除を検討をいたします。
なお、一般的なご案内となりますが、データベース負荷対策として、下記のような対策がございます。

 

と続いていました。

要約すると、なんらか対策を講じてXserverに報告し、問題ないレベルにならないと制限を解除してもらえないということがわかりました。

 

にゃんですとー！

 

つまり、以下の2点を勘違いしていました。

 

• YARPPが原因でない可能性がある。
• データベースの負荷軽減対策を施し、Xserver側に報告しなければならない。（ほっといても解除はしてもらえない）

 

このままだと、新たにWordPressのサイトを作れないため、Xserver側に解除してもらわないといけません。

 

ふ～、困ったもんだ。

 

取り急ぎ、「1週間前に連絡をもらった件については、疑わしきプラグインを止めました。」という旨と、今回頂いたSQLの調査・対応をします。」という旨のメールを返しました。

 

対応について

サーバサイドはそんなに詳しくないので、「とりあえずgoogle先生に聞くかな」と思っていたら、これまたXserverさん、さすがです。

 

メールには、以下の通り対策案を提示してくれていました。

 

▼一般的なデータベース負荷対策
————————————————-
1. レコード数の多いテーブルに対してインデックスを設定する
2. インデックスの構成がプログラムの抽出条件に即したものにする
3. キャッシュの活用によりデータベース接続頻度そのものを低減させる
4. データ更新や削除により発生するオーバーヘッドを解消する
————————————————-

 

1,2については、

 

上記(1)(2)につきましては、有名CMSなどをご利用の場合、
すでに適切に設定されておるケースも多くございます。

 

とのことなので、WordPress（有名CMSだよね？）はすでに適切に設定がなされていると思ったので、今回は、

 

• 疑わしきSQLの調査、対応
• キャッシュの活用によりデータベース接続頻度そのものを低減させる
• データ更新や削除により発生するオーバーヘッドを解消する

 

の3点を考えてみることにしました。

 

疑わしきSQLの調査、対応

Xserverから今回新たに指摘を受けた「XXXXX_term_relationships（XXXXXはインストール時に設定したプレフィックス） 」というテーブルですが、これは、各投稿記事のカテゴリやタグの関連情報が格納されているものだとわかりました。

 

これは固定ページを除いて、どのページでも表示させているのでYARPPプラグインのように削除は難しい機能です。

 

なので、別の箇所、例えばアプリケーションレイヤーのチューニングで何とかできないかを考えて見ることにしました。

 

Google先生にいろいろ聞いたところ、Xserverでいくつかミドルウェアを設定することができ、その中に高速化対策になるものがありました。

 

具体的には、「mod_pagespeed」「FastCGI」それぞれを利用するというものです。

 

これらは、をすることで、結果DBの負荷を下げることになります。

 

それぞれの設定については、Xserverのサイトで紹介していますので参考ください。

 

• mod_pagespeedを利用する
• FastCGIを利用する

 

キャッシュの活用によりデータベース接続頻度そのものを低減させる

過去に「WordPressでキャッシュといったら、W3 Total Cache」というくらい有名なプラグインをインストールしたことがあるのですが、導入したらサイトが表示されなくなる不具合に見舞われ、復旧に時間がかかったことがあるので、簡単でわかりやすい別のプラグインの導入を検討しました。

 

検討の結果、「DB Cache Reloaded Fix」というプラグインを導入しました。

 

このプラグインは、データーベースへのクエリの実行結果をキャッシュ化することで、クエリ実行回数を減らすというもので、今回の対応にうってつけです。

（しかも、設定が超簡単）

 

DB Cache Reloaded Fixについては、データベースのクエリのキャッシュ化で紹介しているので参考にしてください。

 

データ更新や削除により発生するオーバーヘッドを解消する

これは不要なリビジョンを削除し、データベースを最適化するということですね。

 

こちらは、以前にWordPressのリビジョン管理で紹介したプラグインですでに対応済みでした。

簡単に対応できますので 詳細な使い方はそちらを参考にしてください。

 

結果

対応後、Xserverに以下の点対応をした旨を報告しました。

• mod_pagespeedをON
• FastCGIをON
• DBのオーバーヘッドを解消

 

すると、1日後に

 

お忙しい中ご返信いただき恐れ入ります。

 

それではしばらく【負荷】状況を監視いたしまして問題のない水準にまで改善されておりましたら、今回実施いたしましたサーバーアカウントへの個別の制限について、段階的な緩和または解除をいたします。

 

【負荷】状況の調査には数日～１週間ほどの時間を要しますのでしばらくお待ちくださいますようお願いいたします。

 

と連絡が来ました。

 

1週間後、以下の通り制限解除の連絡がありました。

 

大変お待たせいたしました。

改めて【負荷】状況を確認いたしましたところ制限が解除できるレベルまで改善されておりましたので今回実施いたしました制限を『解除』いたしました。

 

現在は通常のご利用が可能な状態でございます。

この度はご対応いただきましてありがとうございました。

 

連絡を受けた直後に、Xserverのコントロールパネルにログインし、無事にアクセス制限が解除されたことを確認しました。

 

所感

いやー、ホッとしました。。。

 

正直、連絡がくるまでの1週間は「改善されてなかったら、プランを上位に上げるとかした方法ないかも」と考えていたのでとにかく安心しました。

 

今回のやりとりで感じたこととして、「アフィリエイターになるためには」といった、アフィリエイター向けに展開されている記事には、

 

読んでもらえる記事を提供しましょう

SEO対策をしましょう

 

といった視点での内容が多いですが、実はサーバの負荷軽減施策についても触れてあげたほうがいいのではないかと思いました。

 

頑張って月間100万PVのサイトにしたはいいものの、サーバの制約条件のせいで、それ以上のアクセスが伸びないとなると、今回のような対応を求められ、また上位プランがないレンタルサーバーの場合は、サーバの移行を視野に入れる必要があります。

（まぁ、最初かアメブロやライブドアブログで始めれば問題ないですが）

 

何はともあれ一件落着！

ということで本日は締めたいと思います。

 

追伸

これで終わったと思っていたら、数ヶ月後にまたまたデータベースアクセス高負荷の連絡がXserverからありました。

 

そちらは 、Xserverから高負荷アラートが来た。その3で紹介しています。

シリーズものなので、興味のある方は、以下「シリーズ記事」より読み進めてもらえればと思います。

 

---

シリーズ記事

• Xserverから高負荷アラートが来た。その１
• Xserverから高負荷アラートが来た。その２
• Xserverから高負荷アラートが来た。その３