KUNISAN.JPブログ - 982 / 1517 ページ

新規書き込み
ページ:1 ... 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 ... 1517

ネットブック(Windows7 Starter)とMySQLの負荷

名前: 小川 邦久 リンク: http://kunisan.jp/ 日付: 2010年2月28日

ネットブック(Windows7 Starter)とMySQLの負荷ネットブック(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管理関連記事(リンク一覧): さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2019) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / Googleマップの有料化(ディベロッパー向け) → Google Cloud Platform / ...(記事連続表示)

MySQL全機能バイブル ~現場で役立つAtoZ~
MySQL全機能バイブル ~現場で役立つAtoZ~ をAmazon.co.jpでチェック
コメント:ネットブック(Windows7 Starter)とMySQLの負荷
名前: 小川 邦久 リンク: http://kunisan.jp/ 日付: 2010年3月1日
コメント:ネットブック(Windows7 Starter)とMySQLの負荷その後、負荷の原因と思われる処理の「2時間以内に…」というのを「同日内に…」という条件に変更してみました。クエリーキャッシュはWHERE条件が一文字でも変わると有効にならないので、時間と共にパラメーターが変化する「2時間以内(今から2時間前のタイムスタンプを指定し、それ以降)に…」よりは、その日のうちはパラメーターが変化しない「同日内に…」の方が、システムの負荷が小さくなると考えたからです。

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

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

ページ:1 ... 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 ... 1517