スポンサーリンク

サーバーの高負荷原因を特定

ホームページのリニューアルに伴い一部のページは新しいサイトにリダイレクトされます。

 

昨年末頃から当ホームページのサーバーの負荷が高く、記事の投稿や更新に時間が掛かっていました。
恐らく閲覧頂いている方へもご迷惑おかけしていた事と思います。
その原因の特定に色々と模索しておりまして、ようやく原因の一つを特定できました。
もちろん、サーバーによって原因は様々で、必ずこれが高負荷の原因というわけではありませんのでご了承ください。
なお、Wordpressを用いたホームページという前提になります。

高負荷の原因となるもの

いくつか原因としてよくあげられるものがあります。

  1. プラグイン(数的、質的双方の観点)
  2. そもそもプラグインの数が増えれば増える程徐々に重くなり、ものによっては単体で重いものもあります。

  3. バージョン
  4. バージョンが新しいものより古いものが劣っている事があります。
    ただ、ものによっては使いにくくなったり、不具合があったりするのでなんでも新しいものが必ずしも良いわけではないですね。

  5. アクセス数(閲覧数)
  6. 嬉しい悲鳴ですね。

  7. アクセス数(閲覧以外)
  8. 閲覧以外のアクセスと言えば、検索サイトの情報収集(クローラー)等があります。
    また、攻撃的なアクセスもありますね。

  9. 転送量
  10. アクセス数とも関係しますが、転送量は平均的なデータサイズ×アクセス数と考える事ができます。
    ※ただ高転送量=高負荷と言われるとそうでもないですが。
    平均的なデータサイズは、画像が大量にあったり、1ページのテキスト量が関係します。
    稀に1ページ内に複数の記事が大量に掲載されているブログがありますが、転送量が不安になります。

  11. 処理量
  12. いわゆる「凝った」ページもブラウザ側の処理ならサーバー的には問題ありません。
    しかし、ブラウザで処理を行うものではなく、サーバーで処理を行うものもあります。
    これが増えれば増えるほど、サーバーで処理を行うわけですから、高負荷になります。
    アクセス数と言えるかもしれませんが、何度もサーバーと通信を行うような仕掛けも負荷になるでしょうね。

今回当ホームページの高負荷の原因の一つは「アクセス数(閲覧以外)」でした。

アクセス数(閲覧以外)への対応

改善効果

基準が難しいもので、これを数値化するのは難しいでしょう。
しっかりログを取り、改善効果を分析すればある程度見えてきます。
しかし、そこに凝ってやれるほど時間がありません。
感覚的なものになってしまいますが、サーバーで「top」コマンドによるCPU利用率を「眺める」という方法をとりました。

CPU使用率の平均的な数値が、半分程度になりました。
そもそもwordpressの処理自体にcpuを使うので、負荷が残っていると言えば残っているんですけどね。

何が悪かったのか

対応内容と直結しますが、直接的な原因として何が悪かったのか?

各種検索サイトのbot類

恐らくこれが最も高負荷の原因であったと考えています。
発端はapacheのアクセスログや、プラグインRedirectionの404エラーでした。
短期間にアクセス集中しているログを見ると、bot、bot、bot・・・
かなりのアクセス数と転送量を費やしていました。

apple-touch-icon

これもかなり高負荷であったと思います。
モバイルからのアクセスの度にapple-touch-iconの404エラーが4~回出力されていました。
wordpress等でサイトを運営されている方で未対応の場合、対応された方が良いかと思います。

DoS攻撃等

ログを集中して確認して初めて知るインターネットの恐怖です。
こんなサイトですら海外IPアドレスから攻撃されるのかと思い知ります。
もちろん対策はしていましたが、サーバーの高負荷の要因にもなり得るという事は改めて痛感しました。

自動バックアップ

記事の編集画面を開いているとき、WordPressは編集内容をバックアップしています。
これにより、複数ページを編集していたりすると、そのページ分バックアップが定期的に動作します。
編集の仕方次第ではありますが、私は多記事同時編集をしばしば行っていましたので、これも高負荷要因の一つとなっていました。

対応方法

原因のそれぞれに対応する事になります。

各種検索サイトのクロールを調整

まず「.htaccess」への記載です。
国内で使われない検索サイトの超々アクセスを削減する事ができます。
もちろん海外の検索サイト上のクロールが止まるという事をデメリットと捉えることはできます。
しかし、限られたサーバーリソースをそこに使う事と天秤にかければ、悪即斬ならぬ悪即断でした。

「.htaccess」に次のようなコードを追記します。

「SetEnvIf」で「XXXXX」を対象の「User-Agent」に書き換えたものを使います。
ここで指定した文字列を持つ「User-Agent」はアクセスできなくなるので気を付けましょう。
「kuruna」は適当に名前を付けただけですのでカスタマイズしてください。

このとき「User-Agent」をどうやって見つけるかがポイントです。
apacheのアクセスログを見ても良いですが、整形するのも面倒ですのでプライグインRedirectionを使いました。
ここに404エラーのログが残っていればUser-Agentが見やすく整形されていますので、botらしきものを見つける事が出来ました。

次に「robots.txt」にも、検索しなくていいディレクトリを記載しました。
ただ、これはあまり効果を感じられませんでした。
記載後も関係なく拒否(Disallow)ったアクセスされています。

もう一つ効果的だったのは、bingのウェブマスターツールからbotのアクセス量を時間毎に調整できます。
「自分のサイトの設定」>「クロール制御」から変更する事ができます。
アクセスをかなり低頻度に切り替えました。
(深夜帯のみ3~4で、他は1)

apple-touch-icon

モバイル端末でサイトへのリンクをホーム画面に追加するときにアイコンが表示されます。
それがこの「apple-toch-icon」のようです。
これにアクセスされていて、404エラーが大量に出力されていました。
「私のサイトが超人気で、皆さんトップ画面に張り付けている」
とは思えないので、モバイル端末でアクセスするごとに取得する動きなのではないでしょうか。

まず画像を用意します。
「apple-touch-icon 作成」
あたりで検索し、作成できそうなサイトで作成する事もできます。
当サイトではそのように対応しました。
ですが、おそらく正方形画像があればそれを使えば問題ないようにも見えました。

作成した「apple-touch-icon*****.png」達をサイトのトップディレクトリに配置します。
そこまでは調べると空気でわかります。
しかし、

をサイトに張り付けて‥‥と言われても「一体どこへ張り付けるの?」、とちょっと戸惑いました。
いや、当然の事なのかもしれないですけどね。
一応、<head>~</head>に記載すると良いらしいので、該当箇所に記載します。
テーマ「simplicity」でしたら、「header-insert.php」に記載する事で該当箇所にはまります。

しかし、この「apple-touch-icon」は「precomposed」というタイプもありました。
これもサイズ毎にアクセスがありました。
「もう、勘弁してほしい」という事で、「.htaccess」に以下を追記しています。

これで「apple-touch-icon.png」にリダイレクトされるので、「apple-touch-icon.png」さえあれば済みます。
※問題あったらすみません。

DoS攻撃等

色々書いてもまずいと思うので一点だけ。
「xmlrpc.php」という、ワードプレスをワードプレスの管理画面以外からコントロールするときに使われるファイルがあります。
私はそんな機能使っていませんが、デフォルトで備わっている機能になります。
これが脆弱性(サイトのセキュリティ上の弱み)となって攻撃の対象とされることがあります。
次のようなコードを「.htaccess」に記載する事でアクセスを禁止させます。

自動バックアップ

これは少々デメリットがありますので設定の際はそのデメリットを加味したうえでご検討ください。
記事の自動更新がされなくなりますので、誤ったブラウザの戻るや閉じるの操作や長期間操作しないで更新等するとせっかくの苦労が水の泡です。

以下をfunction.phpに追記します。

XXXXXXXは関数名になりますので重複が無いよう決めて頂けたらと思います。

終りに

まずは高負荷でお悩みの方に本記事がお役に立てば幸いです。

高負荷の色々な原因を模索するために、色々事故ってしまいました。
事故中にアクセスできなかった方・・・すみません。
おかげさまで、ある程度読み込みは早くなっていると思います。
ものは余り変えていませんが、邪魔が減ったので…。

にほんブログ村 地域生活(街) 東北ブログへ にほんブログ村 地域生活(街) 東北ブログ 米沢情報へ にほんブログ村 教育ブログへ にほんブログ村 教育ブログ 塾教育へ
スポンサーリンク