こんにちは〜。 トラブルブロガーはそろそろ卒業しそうな気がしてます、ユコびん（@yucovin）です(*´∇｀*)

７月頭にお話していたリンあれ500エラー(含503エラー)について、あれからしばらくいろいろ調べていました。 が、リンあれが丁度３周年を迎え、プチ企画を φ=͟͟͞͞φ(｀д´)していたため、この半月間エラー捜索隊はお休みしていたんですよね。 しかし、ずっと放置という訳にもいきません。 ということで、エラー原因追及活動を再開しました。

500（503）エラー／さくらのレンタルサーバー × WordPress（経過説明）

で、現時点の暫定的結論なんですが、『クローラーのアクセス過多』が原因であろうということに。たぶん、ですが。

そこに至るまではかなり紆余曲折してます。 サーバーとか全然専門外なんで…「クローラのアクセスを制限する」なんて記事は読んでいましたが、そうだと言う前に確認や検証しないといけないことがたくさんありました。（こう話してしまうと簡単ですが、何を検証する必要があるのか、ということと、その方法も知らないないので、かなり時間をとられました。この手の話題を扱っているサイトはないわけではないのですが、私同然素人で全く使えないか、専門知識がないとわからないので読み進められないものばかり。間を埋めるような…頭使えば普通の人でも理解出来るサイトプリーズ_:(´ཀ`」 ∠):_ですw）

私のようにエラーに遭遇した人のためになると思うので、具体的な検証方法はまた別エントリにあげるつもりです。今回は簡単なおさらいと経緯を。

リンあれはWordPress、サーバーはさくらのレンタルサーバー利用。

OSバージョン	FreeBSD 8.1-RELEASE-p12 amd64
プラン	さくらのレンタルサーバ プレミアム
CPU	Westmere E56xx/L56xx/X56xx (Nehalem-C)
メモリー容量	5GB
Apacheバージョン	Apache/2.2.25

 

引っ越し当初（今年の４月）から500(503)エラーに悩ませれていました。通常の管理画面での500エラーしばしば、記事公開の際は90%くらいの確率で500エラー。何度もリロードしてやっと更新が反映されると今度は読者さんから「見られません〜！」とTwitter等でリアルタイムに訴えられること多数。

ファイルのパーミッションを確認したり、自分が作ったテーマのphpの確認、プラグインを一つずつ検証し、無効にしていっても状況は変わらず。（プラグインは自分で書けないもの、または書くのがかなり面倒だと思うもののみにし、極力少なくしてあります）

どうしようもなくなったので、さくらに問い合わせしたところ「メモリオーバーでプロセスを強制終了」とのこと。返信には強制終了のログが数行添付されていた、メモリは200MB超えくらいで強制終了がかかるらしい。
（と、ここまで前回のエントリの内容）

それまでも、少しでもサーバーの負担が軽くなるようにと、phpやcssの記述を省略したりまとめたりしてファイルサイズを小さくしたり、細かい画像はスプライトに、 大きい画像も画質を落としてサイズを小さく。画像のブラウザのキャッシュ有効期間を指定したり…、地味な努力も平行してやってました。微々たるものでも意味はある！焼け石に水をかければ0.001度くらい温度が下がる！と思います。

他にも、前から気になっていた他CloudFlareも試しました。ちなみに、CloudFlareは表示速度は速くなり見ている側には効果あるんですが、サーバーの負担という意味では、（当然転送量はもちろん激減しましたが、）CloudFlareからのアクセスがあるのでCPUの負担は減らない、メモリ落ちエラーはもっと増えるという笑える状況でした(^∀^;)　まぁ、読者さんに迷惑がかかってないからいいんですが、検証にならないので現在はCloudFlareは切ってあります。

 問題はどこにある？

実はあの記事を書いた後、Twitterで@kuni92netさんという方に突然話しかけられたんですよ。で、アドバイスをもらい、あちこちぶつかりながらも少しメモリ落ちのエラー原因探求は進みました。世の中には親切な人がいるんですね…有り難いことです。(*´д`*)

まず、@kuni92netさんにコチラの記事を紹介してもらったので、即検証。

WordPressチューニング、その前に使うDebug Bar – さくらのナレッジ

Debug Barというプラグインを利用し、QueriesとSummaryを検証。で、この記事あるような問題は何も起きてくれず…。さらにプラグインを抜いたり入れたり、複数のページを検証しましたがやっぱり問題なく。
（トップページ（index）でDBサーバに送ったクエリ数40、0.05秒、サマリーが0.4秒くらいでした。でも実際ブラウザで表示される時間を見ると、リンあれは激遅です。Facebookページのアレと楽天のアフィがものすごい重く、５秒弱くらいという…）
メモリはページによりますが、25~27MB程度という結果。リンあれのPVが6000~7000／日、多くても１万ちょい／日。さくらのメモリ落ちの200MBを超えるには同時に８ページ。PVから割り出される１分間の平均PVは　6000÷(24×60)=4.1。夜のアクセスが多い時でも１分間６〜８ページが良いところ。１ページあたり５秒メモリを占有してると仮定しても、同時に200MB使うなんて遠い…( ꒪⌓꒪)。そもそもアクセスの少ない朝の５時台にもエラーが出てるからね。もうどうなっているんだか…。
でも同時に8ページのリクエストに応えられないようでは、更新時はアクセスが重なってエラーが出るのは当然か…(-””-;) 

DDを捕まえて「かくかくしがじか」と説明したら一言「さくらのサーバー弱いんじゃんw」と。全然アドバイスになってないから！！Σ(ﾟДﾟ;)　

で、ここでねこ先生からは「そもそのそのプラグインは何を計ってるのか？どこまで信頼できるものなのか？」とツッコミが…orz　そんなことを答えられる能力があるなら、たぶんこんな事で困ってはいないと思うよヽ(`Д´)ﾉぷんすこー
（ここでねこ先生からは、「サーバーって部屋がこまかくわかれてるから、足したのがイコールのメモリ量じゃないと思うよ」 とアドバイスされる。

さくらのサーバー上での実際のメモリ使用量 をチェックせよ

で、次に、@kuni92netさんがphptopを利用してメモリ使用量をみて、負担がかかっているファイルを探してみたらと。自分のサイトを紹介してくれました。

さくらのレンタルサーバーでPHPのメモリ使用量を把握する方法(phptop) - くにくにネット

おぉ〜！ってな事で、早速仕掛けてまる１日分のログをチェックしてみましたφ(｀д´)

結果…一番大きいのが私が管理画面にアクセスしたadminファイルで30MBちょっと。ちなみにエラーが出てている前10秒のリクエストのメモリ使用量を全部足しても100MBもいかない…。んんんー。共用サーバーだからDB動かす分のメモリは制限のかかる200MBには入っていないんじゃないかって、DDも言ってたしなぁ…

 読者さんのアクセス以外のアクセスぅ？？？

と、その後もエラーは出続けているのに、ブログ３周年記事にかまけて絶賛放置中だったわけですが…
実は、そのメモリ使用量のログを見ていて初めて気がついたことがありました。（それまではエラーログしか見てなかったんです…^^;）

「一日のPVが6000~7000なのに、なんで？　私のIPの分はじいてもページアクセスが30000もあるんだろう…(;・∀・)」

はい、ここで「ユコびん、ばかじゃん！」って思った人！挙手願いま〜す！　端から頭はたいていきますから〜(｀･ω･´)ﾉ
この素人の私めが、たくさんの可能性を地道にひとつずつつぶして行った結果なのです〜。そう、「エラーが出るのは、自分の書いたphpファイルのせいじゃないもん(´；ω；｀)」と証明したいだけなのです。

今、リンあれに入れているGoogleアナリティクスや、プラグインのJetpackの統計機能では、通常のアクセス数、つまり読者さんや検索から流れ着いた人の数しか出ません。が、レンタルサーバーのアクセス解析をよく見るとそのほかのアクセスがあることがわかります。

 

うん、ちゃんと見てなかったし、このPagesってのがまさか本当にリクエストを返したページ数だとは思わなかった…、HitsとかFiiesとかと同じノリかと(-””-;)しいません。もうちょっとちゃんとサーバーのアクセス解析をみてみると、多い時間帯では１時間1600のページリクエストがあるようです。1600÷60分＝26.6　これなら処理が８ページ重なることもありそうです。負担がかかれば、それだけ占有する時間も伸びて…。それこそ同じサーバーにアダルトもどきっぽいサイトあったし、いろいろ影響うけるかもしれない。と、勝手に納得。(｡・∀・) ｡_｡))ｳﾝｳﾝ

 WassUpでクローラーを見張れ！

で、このPVの３倍近くあるアクセスは何か？というと、考えられるのはGoogleなどのクローラー（スパイダー）です。あとはスパム的なもの…。（エラーログを見る限りではどこかで集中してエラーが出るわけではなかったので、攻撃をされているわけではないと思いますが。）『クローラーのアクセスがサーバーに負担をかけているので、クロール頻度を調整する』という記事を読んだ事は何度もありましたが、まさか私のところで起きているとは！　そしてこんなに大量とは(n;‘Д‘))n

Googleのウェブマスターツールで調べた結果、Google botの1日あたり平均クロール数は2000。（ちなみにGoogleの場合ウェブマスターツールからクロール頻度を設定出来る。）2千でも多いとは思いますが、残りの2万はどこからなんでしょう…ということで、クローラーのログもとってくれるプラグイン「WassUp Real Time Analytics」を入れて、数日前から入れて様子を見ているところです。WassUpはキャッシュ系のプラグインを切らないといけないので、これまたサーバーへの負担が増えるんでいやなんですけど^^;)　で、流石に毎日1万、2万のクローラーのアクセスを全部見るのは大変なので、チラチラ覗いているだけですが、グーグル以外にもたくさんクローラーが来ているようです。中には、存在しないページにリクエストをたくさん送ってくるものや、スパム系とされるクローラーもあるようです。

またいろいろ調べつつ、robots.txtでクロール頻度を設定してみようと思います。（robots.txt見てくれない悪いbotもいるらしいけどね…^^;　そゆのは.htaccessで対応するらしい。

とういうことで、簡単に今までの流れを説明しようとしたら全然簡単じゃなくなっちゃいました…(・∀・;)何時間書いてるんだワシ。いや、でもかなりはしょってます。やったこと全部書いてないしw

様子を見て、またちゃんとエントリにあげますが…
結論として、サーバーの引っ越しはする事は私の中では決まってます。私のサイトの作りでメモリ200MB制限はきついです。もっともっとシンプルにしてメモリ消費しそうなものを排除して軽いページにする…という選択肢はないんですよね…リンあれには。（まさかのMTにしちゃうとか…、うーんそれはものすごく面倒。）そして、今まで一番一日のPVが多かった時（FC2時代）が1万8千くらいで、もしそんな事が起きたらクロール頻度が改善されたとしても今のさくらのレンタルサーバーでは確実に落ちると思われ…。そんなんじゃ、FC2から引っ越した意味ないやい！(；∀；)　まぁ、リンあれなのでバズる可能性は限りなく低いと思いますが、でもまたあるかもしれないなぁと。落ちたら絶対ムッとすると思います（笑）
それに、同時に8ページ以上の処理が出来ないようでは、ブログを更新する度に500エラーが出続ける現象は無くならないですよねぇ…。そうなると結論はお引っ越しかと。

 

共用レンタルサーバーって、容量だとか、ドメインやDBどれだけOKとか、一歩進んでも転送量が何GBだとかそんな情報しかないじゃないですか。公式にサーバーのメモリ発表しているところはほとんどないですよね。１契約あたりなんて情報はまずないし…(´Д｀;)`、　WordPressはメモリ食いなのに、メモリの少なそうなレンタルサーバーがこぞって「WordPress簡単インストール！おすすめ」なんて紹介してる（されてる）のもなんだかなぁ…。

レンタルサーバー借りてWordPressやりたいなら、メモリの量ってすごく大事だと思いました。いやぁ、何事も経験ですね〜(｡・∀・) ｡_｡))ｳﾝｳﾝ　って、サーバについてはほぼ素人なので、今回は結構苦しかったョ

 

引っ越し先は、公式にメモリ16GBをうたっている（１契約のメモリ制限はわからないけど）エックスサーバーがいいかなぁと考えてるところです。今ならドメインが無料で１つもらえちゃうキャンペーンやっているらしいΣ(ﾟДﾟ;)サーバーを契約してるかぎりは更新料も無料って…。論ユコをここで！と思ったり。2013年8月9日(金)12:00 ～ 2013年8月16日(金)18:00までのようです。