アプリ版:「スタンプのみでお礼する」機能のリリースについて

ロードアベレージが高いのですが、CPUもディスクIOも低く、これはどういったことが原因なんだろうと悩んでいます。
topやsar等の結果は以下の感じです。
VPSサーバーでapache mysql phpが動いていて、mysqlはほとんど使っていなくて、apacheが原因ということはわかっています。
apacheのプロセスがたくさん作られています。PV等からもうスペック不足だなとは思っていて近々サーバーを引っ越すのですが、
これの原因をつきとめてすっきりさせたいところです。http.confをいじれば解決する問題なのでしょうか?
本やブログなどを読んでもロードアベレージの原因はCPUかディスクIOであると書かれていてそう思っていたんですが、この状態だと納得できません。よろしくお願いします。

load average: 10.78, 18.97, 20.37

Cpu(s): 2.9%us, 1.8%sy, 0.0%ni, 95.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1572864k total, 587936k used, 984928k free, 0k buffers

06:20:01 PM CPU %user %nice %system %iowait %steal %idle
06:30:01 PM all  5.53 0.00 3.37 0.01   0.00 91.10
06:40:01 PM all   3.40 0.00 2.12 0.00   0.00 94.48


03:20:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
06:40:01 PM 776820 796044    50.61 0    0   0    0    0.00    0
06:50:01 PM 709144 863720    54.91 0    0   0    0    0.00    0
07:00:01 PM 914668 658196   41.85 0   0    0   0    0.00    0

A 回答 (3件)

「ニワトリとたまご」問題的な勘違い(結果と原因の取り違え)をしていないか、


ちょっと気になりました。

まずは、前提知識から確認させてください。
1.ロードアベレージは何の数値なのか?
 ロードアベレージとは、実行可能待ちプロセスの数です。
 窓口(CPU)の前で待たされている人(プロセス)が多いことを示しているだけです。

 よく言われるのは、
  「CPU負荷やディスクIOが高いと、左記の状態の影響で、実行可能待ちプロセス数が増加し、
   ロードアベレージが高くなる」
 つまり、
   "原因:CPU負荷、ディスクIOが高い"→"結果:ロードアベレージが高い"
 という話であり、原因と結果と取り違えないよう注意して下さい。
 インターネット上でも、よく勘違いしている人がいます。

次に、今回の現象の原因分析について
2.ロードアベレージが高い原因は何なのか?
 "ロードアベレージ"="実行可能待ちプロセスの数"なので、

 >apacheのプロセスがたくさん作られています
 ということが直接原因の可能性が濃厚です。
  apacheのプロセスがたくさんある
   →たくさんのプロセスが窓口(CPU)前で待たされている
    →ロードアベレージが高くなる
 という考え方です。

3.「apacheのプロセスがたくさん作られている」原因は何か?
 "apacheのプロセス(窓口)"がたくさん作られている原因ですが、
 ア.大量HTTPリクエストを処理するために"apacheのプロセス(窓口)"がたくさん必要。
  という処理量に起因する原因。
 
 イ.一つ一つのHTTPリクエスト処理に時間が掛かっているため、
  "apacheのプロセス(窓口)"がたくさん必要。
  という処理の特徴に起因する原因。

 と2通りが考えられます。
 今回の場合は、localicaさんの回答にあるとおり、
 イのパターンの原因でしょうね。
 >CPUの負荷が低い割りにキューの処理が遅い理由は1つ1つのジョブに
 >時間が掛かっていると思われます。
 >従って、1つ1つのジョブに時間を要する理由が原因と思われます。

イのパターンの場合、
 サーバ更新で処理能力を増強するとしても、
 ボトルネックを明らかにして、ボトルネック部分を性能増強しないと性能向上は見込めません
 例えば、WEBサーバのCPU能力は今でも十二分に足りており、
 これを増強しても性能向上は見込めません。

 また、アプリケーションの性能不具合が原因で待ちが発生している場合、
 サーバ処理能力を向上させても、問題解決にはなりません。
 アプリケーションの性能不具合の具体としては、
  ・DB排他ロック待ち
  ・ファイル排他ロック待ち
  ・DBテーブルへのアクセスプランが最適化されていない
  (インデックスを利用していない、全文検索を行っている等)
  ・DBMS(mysql)の各種キャッシュが枯渇している
 などがあります。

 このアプリケーションの性能不具合を修正するには、
 ボトルネック部分を明らかにした上で
 プログラム改修やDBMS(mysql)の設定修正が必要になります。

 一度、アプリケーションの性能不具合が発生していないか、
 専門家に分析してもらうことをオススメします。
    • good
    • 0
この回答へのお礼

ありがとうございます。
勘違いはしていないと思ってます(笑)

ただ、ロードアベレージの概念はわかっていたつもりでしたが、たいていCPUやディスクIOが原因で~~~みたいな書かれ方で、それらを調べる方法しか書かれていなかったものなので、自分の中で仮説はあったんですが、いまいち自信が持てずサーバー移転の前に原因をはっきりわかりたいと考えていました。

サーバー移転も行い、その後は一応負荷があがることなく動いていますが、お二人のお話を聞いて原因の目処はたちました。
データベースがやはりレスポンスが悪そうです。主にテーブルロックとインデックスの問題だと思います。

今後はデータベースのチューニングをしていこうかと思います。

皆さんありがとうございました。

お礼日時:2010/10/26 14:43

>apacheが原因ということはわかっています。



なぜapacheが原因と思われるのでしょうか?
apacheが原因ならそこを見直しては?

>apacheのプロセスがたくさん作られています

たくさんっていくつでしょうか?

>ロードアベレージの原因はCPUかディスクIOであると書かれていて

一般論で言えば上記通りですが、他のIOは思い浮かびませんか?

CPUの負荷が低い割りにキューの処理が遅い理由は1つ1つのジョブに時間が掛かっていると思われます。
従って、1つ1つのジョブに時間を要する理由が原因と思われます。

以下は勝手な推測ですが、Webサービスのロジックがネットワーク、或いはDBの応答を待っているのではありませんか?
仮にネットワーク越しに値を取得してから処理するようなロジックでは相当にパフォーマンスが悪いでしょうし、MySQLに無駄な処理をさせていませんか?
後はネットワーク帯域の問題の可能性もあります。
いずれもきちんとボトルネックを計測すればある程度推論は立つと思います。

時間が無いので中途半端な回答になりましたが、ログ解析をお勧めします。

この回答への補足

>apacheが原因ということはわかっています。
>apacheのプロセスがたくさん作られています

ロードアベレージが高くなる時はapacheのプロセスが多くなっています。
たしか100以上はあったはずです。

>以下は勝手な推測ですが、Webサービスのロジックがネットワーク、或いはDBの応答を待っているのではありませんか?

たしかにその可能性はあります。ネットワークはともかくDBの可能性は否定できません。
この質問の以前にDBも同じサーバー内にあったのですが、DBのCPU使用率が高く、ロードアベレージの高い原因はDB
だと考え(決めつけて)、WEBサーバーから切り離したんですが、結局あまり変わらなかったという経緯があります。
確かにリクエストがあると基本DBに何回も問い合わせするページがあるので、まずはその辺を疑ってみたいと思います。


>時間が無いので中途半端な回答になりましたが、ログ解析をお勧めします。

時間がない中ありがとうございます。

補足日時:2010/10/22 14:27
    • good
    • 0

root権限はありますか。


一度、再起動してみて下さい。

又、各種ログをご覧になっていますか。
特に、エラーログです。

PLESKから管理しているのでしょうか。??

この回答への補足

再起動は運用中ですのでできません。
ログは見ていますが基本的に異常な所はないと思います。←ここは自信なし

PLESKは入っていますが私はつかっておりません。

補足日時:2010/10/22 14:16
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!