No.2
20
2
31pt
Load Average 50以上でなおかつまだ動作しているというのは、LinuxにおいてはCPU負荷よりディスクIO負荷でしょうね。実際にそういう経験もあります。
それはどこかのプロセスがファイルを常に読み書きしてる事を表しますから、まずそれを探します。とはいってもこんな状態だとtopが立ち上がるまで何分もかかったりするので、原因不明の場合は大変です。外部からのアクセスが原因だとわかってるなら、一度ネットワークを遮断するのもいいでしょう。
もっとも、こんなに派手にリソースを使うアプリケーションなんて、そのホストを動かしてる人にはすぐピンと来るでしょうから、そのプログラムを一度落してしまうのが早いかと思います。
そして一定以上のディスクアクセスをしないように、設定を見直すなりして再起動、ですね。
例えばウェブサービスの場合なら、apacheのMaxClientsを低くする。そして負荷がかかるCGIなりなんなりを調査します。ファイルを配布してる場合なら、mod_limitipconn で並行ダウンロードをしてるユーザーを撲滅するだけで、相当負荷が下がります。
接続数／帯域制限で無法なダウンローダを撃退（4/4） − ＠IT
しかし、一番の解決はハードウェアを更新する事かもしれません。それでも足りなければクラスタリングやDBのレプリケーションなどを駆使して負荷を下げることになると思います。
http://www.thinkit.co.jp/free/article/0610/1/6/
や
http://www.linux.or.jp/JF/JFdocs/openMosix-HOWTO/
などを参照してください。
No.1
3344440
28pt
http://www.atmarkit.co.jp/flinux/rensai/root07/root07b.html
とりあえず、top や free でＣＰＵ使用率とメモリ使用量を調べるところから。
一時的な対処であれば該当プロセスを kill もしくは再起動。
解決方法は原因しだいなのでなんともいえない。
Web サーバーであれば CGI 等のアプリケーションの設計見直しや、各種パラメーターの見直し、メモリの増設等で解決する場合が多い。
ただし、Loadaverageが50以上というのは実際にはほとんど動いていない状態で確認する事すら難しいでしょう。
どちらかというとパラメーターの読み違いを疑います。
No.2
202
ここでベストアンサー
31pt
Load Average 50以上でなおかつまだ動作しているというのは、LinuxにおいてはCPU負荷よりディスクIO負荷でしょうね。実際にそういう経験もあります。
それはどこかのプロセスがファイルを常に読み書きしてる事を表しますから、まずそれを探します。とはいってもこんな状態だとtopが立ち上がるまで何分もかかったりするので、原因不明の場合は大変です。外部からのアクセスが原因だとわかってるなら、一度ネットワークを遮断するのもいいでしょう。
もっとも、こんなに派手にリソースを使うアプリケーションなんて、そのホストを動かしてる人にはすぐピンと来るでしょうから、そのプログラムを一度落してしまうのが早いかと思います。
そして一定以上のディスクアクセスをしないように、設定を見直すなりして再起動、ですね。
例えばウェブサービスの場合なら、apacheのMaxClientsを低くする。そして負荷がかかるCGIなりなんなりを調査します。ファイルを配布してる場合なら、mod_limitipconn で並行ダウンロードをしてるユーザーを撲滅するだけで、相当負荷が下がります。
接続数／帯域制限で無法なダウンローダを撃退（4/4） − ＠IT
しかし、一番の解決はハードウェアを更新する事かもしれません。それでも足りなければクラスタリングやDBのレプリケーションなどを駆使して負荷を下げることになると思います。
http://www.thinkit.co.jp/free/article/0610/1/6/
や
http://www.linux.or.jp/JF/JFdocs/openMosix-HOWTO/
などを参照してください。
No.4
161
31pt
CPU使用率(ロードアベレージとは別もの)を見てみると何かわかるかもしれません。 ロードアベレージが上がっていてもCPU使用率が100%になっていなければ私の経験上ではほとんどディスクI/Oです。
Webアプリケーション自体が原因ではなかったこともあります。
その時はメーリングリストエンジン(Mailman)でした。 メーリングリストの書庫を作成しないように設定したら嘘のように軽くなりました( ロードアベレージ20から0.2以下へ)
また、Webサーバーのプロセス数やKeepAliveの値を調整することも非常に効果あります。極端な値にすることでデータベースの負荷を下げたり処理待ちの状態を解消できます。このへんはGIGAZINEの
記事が参考になると思います。
パフォーマンスチューニングを行う上でポイントとなるのは定期的なパフォーマンスのモニタリングです。過去の指標があれば他のパフォーマンスデータとの相関から何処が原因なのかすぐにわかるようになります。今からでも遅くないので(１日分のデータがあれば十分)SNMPやsystatで取得してみてはいかがでしょうか。
以下、参考になるURLです。
Web+DB PressのVol.34の「性能カイゼン大作戦」という特集は非常に参考になりました。
http://www.gihyo.co.jp/magazines/wdpress/archive/Vol34
GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
http://gigazine.net/index.php?/news/comments/20060601_loadavarag...
31
29
1
1
禁止リスト追加と・・・。