- ベストアンサー
ロードアベレージが高いのはCPUやディスクIOのせい?原因を解明したい
- ロードアベレージが高いのですが、CPUもディスクIOも低い状態です。この原因を解明し、問題を解決したいと考えています。
- VPSサーバーでapache mysql phpが動いており、mysqlはほとんど使用されていませんが、apacheのプロセスが多くなっています。サーバーのスペック不足が原因と考えられます。
- 本やブログなどでは、ロードアベレージの原因はCPUかディスクIOであると書かれていますが、この場合は納得できません。どういった要因がロードアベレージの高さに関係しているのでしょうか。
- みんなの回答 (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)の設定修正が必要になります。 一度、アプリケーションの性能不具合が発生していないか、 専門家に分析してもらうことをオススメします。
その他の回答 (2)
- localica
- ベストアンサー率52% (202/385)
>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に何回も問い合わせするページがあるので、まずはその辺を疑ってみたいと思います。 >時間が無いので中途半端な回答になりましたが、ログ解析をお勧めします。 時間がない中ありがとうございます。
- mega2007
- ベストアンサー率33% (40/118)
root権限はありますか。 一度、再起動してみて下さい。 又、各種ログをご覧になっていますか。 特に、エラーログです。 PLESKから管理しているのでしょうか。??
補足
再起動は運用中ですのでできません。 ログは見ていますが基本的に異常な所はないと思います。←ここは自信なし PLESKは入っていますが私はつかっておりません。
お礼
ありがとうございます。 勘違いはしていないと思ってます(笑) ただ、ロードアベレージの概念はわかっていたつもりでしたが、たいていCPUやディスクIOが原因で~~~みたいな書かれ方で、それらを調べる方法しか書かれていなかったものなので、自分の中で仮説はあったんですが、いまいち自信が持てずサーバー移転の前に原因をはっきりわかりたいと考えていました。 サーバー移転も行い、その後は一応負荷があがることなく動いていますが、お二人のお話を聞いて原因の目処はたちました。 データベースがやはりレスポンスが悪そうです。主にテーブルロックとインデックスの問題だと思います。 今後はデータベースのチューニングをしていこうかと思います。 皆さんありがとうございました。