- - PR -
apacheが遅い原因（libhttpd.ep？)
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-06-13 08:20
お世話になります。今バリバリ遅い時間帯です。vmstat 10 を実行しました。
現にphpのページをロード中が10分以上続いています。以前は1秒未満で開いておりました・・・ [root@grwserver shells]# vmstat 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 3 6 1 29700 10128 107896 795616 1 2 5 32 94 94 4 1 94 0 10 1 29700 10120 107940 793920 0 3 1506 80 314 384 2 1 97 0 14 1 29832 9364 107972 793104 0 18 1456 64 297 382 1 2 97 0 14 0 30216 9348 108008 793268 0 44 1512 185 319 415 4 1 95 0 13 0 30484 9348 108020 793248 2 34 1399 72 300 304 2 1 97 3 8 0 30616 9380 107940 792920 0 19 1556 46 317 334 2 1 97 0 14 1 30880 9336 107840 791044 2 35 1647 97 344 450 2 2 96 0 15 1 31236 9516 107856 788160 2 44 1492 100 311 426 3 1 95 0 13 0 31540 9648 107840 786504 3 38 1466 95 331 386 2 1 97 1 15 1 31940 9504 107888 782264 3 54 1440 135 301 465 3 2 96 0 13 1 32344 9332 107900 781292 3 62 1268 158 297 466 2 1 96 0 13 0 32672 9428 107868 781072 6 43 1516 75 307 439 2 1 97 0 11 0 32760 9352 107780 779968 13 34 1364 50 288 453 2 3 96 0 13 0 32856 9388 107580 780428 29 61 1283 85 286 488 4 3 93 1 11 0 32984 9632 107512 780112 18 22 1505 54 294 603 1 1 98 0 11 0 32984 9444 107448 780448 14 6 1430 28 291 592 1 1 98 0 12 0 33116 9832 107456 778656 10 19 1444 44 296 568 2 1 97 0 17 0 33252 9612 107472 779176 14 21 1475 58 297 500 2 2 97 1 13 0 33764 9564 107444 777376 21 65 1249 102 270 443 1 1 98 0 15 0 34392 9420 107404 773320 8 77 1358 106 286 474 3 1 95 1 20 0 35240 9232 107272 771552 4 103 1364 126 291 423 2 2 96 | ||||
|
投稿日時: 2005-06-13 12:05
こんにちは。
vmstat の結果を見ますと、CPU使用率もメモリも問題なさそうですね。 ※スワップが実メモリの3〜4% は十分フツーです。メモリに余裕があっても kernelは積極的にスワップしようとしますから…( 確か 2.4系から ) 一番気になるのはブロックしているプロセスの数の多さ ( procs の b )、それからディスク読み込み ( io の bi ) でしょうか…。DBへのクエリー( SELECT ) がやはりネックっぽいですね。 DBのパフォーマンスの問題なのか、ディスクトラブルなのかは分かりませんが。 手として、 ・DB のチューニングや解析 ・ディスクのベンチマーク測定 ・syslog にディスク周りのエラーが出てないか確認 ・Apache の同時接続数を調整することで、DB接続数を間接的に調整し、限界を見極める 等があるでしょうか。 以上、ご参考まで | ||||
|
投稿日時: 2005-06-13 12:52
メモリ不足ですね。
siとsoが同時にずっと出たまま、これはスワップインするために スワップアウトするのを繰り返すという、劇的なパフォーマンス低下を ひき起こす状態です。 # si/so が出なくてもメモリ不足ということも起こるんですが、 # いまそのことは置いておきます。 左から2番め、bのところはI/O待ちのプロセス数ですがこれが 常時たくさん出ている。でもって、いちばん右のidをみると CPUがほとんどアイドルであることが分かります。I/O待ちばかりで、 CPUが働くことができないためです。 なぜI/O待ちしているのかというと、スワップイン・スワップアウトを 繰り返しているからです。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-06-13 12:54 ] | ||||
|
投稿日時: 2005-06-14 11:20
こんにちわ。
これは、メモリ不足っぽいですね。 引用： ＞また、cronでは夜中2時からpg_dumpをしてそれをtarで圧縮してbackupサーバーにsftpをしておりますが、backupサーバーのファイル更新日時を見ると、朝4時頃には終わっております。 ＞ ＞ は！これはsftpでコピーし終わった時刻ではないのでしょうか・・・ で、メモリが使われる。 で、DB接続、おもにSELECT文で読み出そうとした際にメモリを使うのでスワップイン、アウトで表示時間が遅くなる。 引用部分でつかったメモリが開放されてメモリが使えるようになり速度が戻る。 ってな感じですかね？ 重い時にできるなら一回再起動する。（これで強制的にメモリ開放を行う。 元の速度に戻れば、上でいった事になる。（少なくとも次の日までは引用部分で使ったメモリが他で使える。 後はなにかな・・・MRTGとかでメモリ状態がどううつってるのか確認かな。 メモリは多すぎても困る物じゃないから増設してテストするもいいんじゃないかなと。 #RH9にあるのかはしらないけど、メモリ開放ツール 又は コマンドってあるのかな？ そこまで詳しいわけじゃないので結構適当部分ありますので^^; [ メッセージ編集済み 編集者: kami 編集日時 2005-06-14 11:21 ] | ||||
|
投稿日時: 2005-06-14 11:53
素人考えなのですが…
メモリって、そんなに食い潰してしまう（押さえている時間が長い）ものなのでしょうか？ 1GB くらい積んでいて、平常時？は 82MB くらいしか使っていませんよね。 （初回ポストの free より） 「朝方5時から9時くらいまでだけ強烈に遅い」 が引っかかるのですが、cron で何か他に処理を動かしていたりしないでしょうか？ # 処理の遅い時間帯に、top で M してみたい気も _________________ はゆる Smile, Smiles make me happy. | ||||
|
投稿日時: 2005-06-14 12:12
最初に思ったのは、「ダンプしてtarで固める際にメモリが足りなくて
apacheのプロセスがスワップアウトされ、そのままになっているのでは ないか」ということだったのですが、どうもそういうことではない。 で、メモリを使いっぱなしになるか、ということですが... 何時間も前に一度使ったきりのところは inactive で clean なので 捨ててしまってよい。だから、メモリが逼迫するのには関係ないはず。 でも、メモリが足りていないのは確実です。 原因の予想としては「DBのサイズが運用開始当初よりも膨らんで、 メモリが足りなくなった」というところですかね。 メモリが足りないのでスワップイン・スワップアウトを繰り返して パフォーマンスが大幅低下 → スループットが下がったので 未処理のリクエストが溜まる → そのことがさらに状況を悪化させる という悪循環に陥って、どうしようもなくパフォーマンスが 落ちているのでしょう。 メモリを食っているヤツの正体はカーネルなので、top とかで 見ても分からんでしょう。 # ここまでの予想が当たっていれば、ですが。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-06-14 12:16 ] | ||||
|
投稿日時: 2005-06-14 12:29
なるほどです。ありがとうございます m(_ _)m > ぽんす さん
私が考えたのは… どういう web システムを構築されているのか分からないので、ちょっと前に身近な人がハマっていた 「Namazu のインデックス作成が〜（涙）」 みたいなパターンも、あり得るのかなぁと思ったんですね 
（ちょうど朝方に cron に仕込んでいたのでした） _________________ はゆる Smile, Smiles make me happy. | ||||
|
投稿日時: 2005-06-14 16:41
みなさまご回答ありがとうございます。
なにぶん不勉強で皆様のお話についていくのがやっとです。。。
こちらに関しては今年2月の時点のバックアップデータを残しておくことを条件に 古いデータを削除しておりまして、2月時点よりはデータ量は減っております。（↓） # ls -la -rwxrwxr-x 1 root root 17344463790 2月 16 19:46 mydb_050216_1700.dump -rw-r--r-- 1 root root 12722650853 6月 14 03:59 mydb.dump また、遅くなったなどで削除したのではなく。削除する前も普通に動いておりました。。 少なくとも今よりははるかに快適でした。 ここで、2月からの時系列でもう一度思い当たることを「供述」いたします。 ・上のように2月16日にバックアップを取ってデータを絞りましたがその後は快適に動いておりました。 ・3月半ばに突然クライアントからのアクセスが遅くなりました。症状は今と同じ朝方に遅くなり、9時くらいに解消されます。そして土日はほとんど休みで平日とは比べ物にならないほどアクセス数が少ないはずなのに土日が遅いという現象が続きました。 ・4月半ばに土日に出勤してインターネット側からのアクセスをシャットアウトしまし。（ファイアーウォールでアクセス拒否にしました）。するととたんに速くなりましたのでインターネットから誰かが悪さをしているのかと思い、apacheを最新の1.3.33にしました（それまでは1.3.31）。 ・するとそれから5月のGWまでは快適に動いていたのですが、GWを空けるとまた同じように遅くなっていていました。またインターネットからのアクセスを閉じると直るのかと思いましたが今度は直りませんでした。 ・そして現在に至ります。 これが経緯ですが、とりあえず私にほうではcronで夜中に実行するshellスクリプトの最後で、shutdown -r now を書き加えて実験しようと思います。明日の朝方に結果が出ます。 （apacheのrestartで十分でしょうか・・・） | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。