KUNISAN.JPブログ - 1205 / 1740 ページ

ネットブック(FRONTIER FRNU305)を自宅サーバー化して、PHP+MySQLのアクセス解析プログラムを乗せたのが約10日前。当初はデータ量が少ないことから動きが軽く、ネットブックのファンも静かだったのですが、最近になって管理画面が時折フリーズしたり、ファンがうなるようにもなってきました。

タスクマネージャーでリソースの観察をしてみると、メモリの方はそれなりに余裕があるものの、CPUの使用率が100%に達することがあり、これがフリーズやファンがうなる原因になっていたようです。

アクセス解析プログラム中、頻繁に行われる処理の中で、「2時間以内にIPアドレスとユーザーエージェントの両方が同じデータが記録されているか確認を取る」というものがあり、これが1日4万回もあることから、大きな負荷がかかっているものと思われます。そのうち、「IPデカ(ブログパーツ)」だけで1日2万回に達しており、混み合う時には1秒に数回の処理があります。IPデカのアクセスデータ数は既に27万件に達していて、このテーブルから1秒に何回もクエリーでデータを抽出するのは、大変な負荷になるということは容易に想像できます。

Windows付属のパフォーマンスモニターで、さらに詳しく動向を見てみると、1～2時間に1度、3～5分の長さでCPU使用率が100%に達して、この間に動きが非常に重くなってしまうことがわかりました。

「どうにかならないかな…」と思い、MySQLの本を流し読みしていたところ、MySQLのデフォルトの状態では「クエリーキャッシュ」の設定がされていないことがわかりました。早速phpMyAdminから、下記のコマンドを入力してクエリーキャッシュをセットしました。

SET GLOBAL query_cache_size = 1048576;

キャッシュサイズは約1MBです。当初はこれで「軽くなったかも」と思いましたが、やはり1～2時間に1度、CPU使用率が100%になってしまう現象は変わりませんでした。キャッシュ容量をチェックしても「全て食い尽くす」ようなことは無かったので、クエリーキャッシュの設定だけではCPU使用率が高くなる現象は防げないようです。

今のところ、動きが重くなるタイミングがあるとは言え、全く動きが取れなくなるような状況ではありませんが、今後事態がさらに悪くなるようであれば、プログパーツをアクセス解析の対象から外そうと思います。ブログパーツ以外のテーブルのサイズはいずれもブログパーツのものより大幅に小さいものばかりで、これだけでも負荷が半分以下に減少することが見込まれます。

それにしても、ブログパーツはサーバーのリソースを食うし(本サーバーの方も最近たまにエラーが出ます)お金にはならないし、運営していてあまりいいことがありません…。「IPデカ」のように人気が出るのもいいことなのですが、今後アクセスがありすぎて他のサービスにまで影響してしまうようなことがあると、ブログパーツの公開を中止せざるをえないかも知れません。苦渋の選択になりますね…。





Web管理関連記事(リンク一覧): SPF、DKIM、DMARCの設定とネームサーバー(DNS)設定のトラブル / さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2018) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / ...(記事連続表示)

MySQL全機能バイブル ~現場で役立つAtoZ~ をAmazon.co.jpでチェック

その後、負荷の原因と思われる処理の「2時間以内に…」というのを「同日内に…」という条件に変更してみました。クエリーキャッシュはWHERE条件が一文字でも変わると有効にならないので、時間と共にパラメーターが変化する「2時間以内(今から2時間前のタイムスタンプを指定し、それ以降)に…」よりは、その日のうちはパラメーターが変化しない「同日内に…」の方が、システムの負荷が小さくなると考えたからです。

結果はほとんど変わらず、やはりCPU使用率が100%に達する現象は発生してしまいました。残念…。

最後の手段として、ブログパーツをアクセス解析から外してみました。当初はCPU使用率の平均値が30%強(普段は20%台後半で、たまに100%に達してしまうため)だったのですが、ブログパーツを対象から外したところ、「7%」と大きく減少しました。12時間稼働させて100%に達することは一度もありませんでした。やはりブログパーツのリソース食いはかなりのものです…。