パフォーマンス

高い負荷平均、低いCPU使用率-なぜですか？



High Load Average Low Cpu Usage Why



解決：

解決策1：解決策1：

さらに調査すると、パフォーマンスの問題は主に2つのシステム（Oracle SSXAとUCM）間のネットワーク呼び出しの数が多いことが原因であると思われます。呼び出しは高速ですが、十分にシリアル化されているため、CPU使用率が低く（主にI / Oを待機）、平均負荷が高く（多くの呼び出しが処理を待機しています）、特に応答時間が長くなります（応答時間の累積による）。

この問題についての洞察に感謝します！



解決策2：解決策2：

「高負荷平均」と言うときは、prstatがの出力値の下部に「負荷平均」を示していることを意味すると思います。

合計：135プロセス、3167 lwps、平均負荷：54.48、62.50、63.11
これらの数値は、topが提供する数値と似ており、おそらく実行中のプロセスの平均キューサイズを意味します。これは、使用されているプロセッサ時間の割合ではなく、実行時間のためにCPUに嫌がらせをしている「もの」の数です。確かに、これらはかなり高く見えますが、これはすべて、実行しているアプリによって異なります。スロットを取得すると、プロセスは実際にはあまり機能していない可能性があります。トップに関する良い説明については、ここを参照してください。
 
 
 
私はWebLogicに精通していませんが、一般に、Apache Tomcatを使用すると、要求が少ないように見えるものに対して、多くのJavaスレッドを同時に生成できることに気付きました。これらの高い平均負荷数を引き起こしているのはこれである可能性があります。必要に応じて接続プールを使用してバックエンドに接続していることを確認し、接続を処理するためにアプリで使用できるアイドルスレッドの数を増やすことを検討してください（WebLogicでこれを行う方法がわかりません。Tomcatにはコネクタごとのスレッドプールがあります。一般的なエグゼキュータスレッドプール）。これを行わないと、リクエストを処理するために新しいスレッドが生成される可能性があります。
 
パフォーマンスに関しては、あなたは釘付けにする必要があります 何 アプリの一部が苦しんでいます。それは、WebLogic / Java側で発生している処理、データベースアクセス、DNSルックアップ（何らかの理由で実行されている場合...）、ネットワークの問題、またはOS上の何かです。
 
99％の確率で、それはあなたのコードであり、それが物事を支えているデータベースとどのように通信するかです。次に、Webアプリの構成になります。この時点を過ぎると、アプリから最後のミリ秒を絞り出すか、同じハードウェアでより高い同時実行性を提供することを検討します。このきめ細かいパフォーマンスチューニングには、メトリックが必要です。
 
 
 
Javaの場合、JavaMelodyをインストールすることをお勧めします。それはあなたのプログラムが何をしているかに関する多くの情報を提供し、それが時間を費やしている場所を絞り込むのに役立ちます。私はTomcatでのみ使用しましたが、JavaEEコンテナ/サーブレットで問題なく動作するはずです。
 
Javaを調整する方法はいくつかあるので、パフォーマンスガイドラインを見て（おそらくそうしていると思います）、プログラムに適した正しいヒープサイズなどを設定していることを確認してください。 Java Melodyは、消費しているJavaのヒープのサイズ、およびガベージコレクターの動作の程度/プログラムを中断してオブジェクトをクリアする頻度を追跡するのに役立ちます。
 
それがお役に立てば幸いです。さらに情報を提供していただければ、この回答を更新して、ニーズに合わせてさらに磨きをかけることができる場合があります。
 
 
解決策3：解決策3：
 
ちなみに、負荷平均には、ディスクアクティビティを待機しているもの（つまり、ディスクに嫌がらせをしているもの）とCPUを待機しているものも含まれます。これは両方の合計です...したがって、どちらかで問題が発生する可能性があります。
 
http://en.wikipedia.org/wiki/Load_(computing）を参照してください。「Linuxには、[負荷平均で]中断できないスリープ状態（通常はディスクアクティビティを待機している）のプロセスも含まれています。」
 
ちなみに、私が遭遇した特定の問題は、平均負荷が高いだけでなく、アイドル状態のCPUが多く、ディスク使用量が少ないことでした。
 
少なくとも私の場合、I / Oを待機しているスレッド/プロセスが負荷平均に表示されることがあるようですが、 いいえ 'await'列の増加を引き起こします。しかし、それらはまだI / Oバウンドです。
 
jrubyで実行すると、次のコードの場合にこれが当てはまることがわかります（それぞれに大量のI / Oを使用して100スレッドを実行するだけです）。
 
100.times {Thread.new {loop f.seek 10_000_000_000; f.puts'a ';終わり}}
これは次のようなトップ出力を提供します：
 
トップ-17：45：32アップ​​38日、2：13、3ユーザー、平均負荷：95.18、50.29、23.83タスク：合計181、実行中1、スリープ中180、停止0、ゾンビCPU 0：3.5％us 、11.3％sy、0.0％ni、85.1％id、0.0％wa、0.0％hi、0.0％si、0.0％st Mem：合計32940904k、使用済み23239012k、無料9701892k、バッファー983644kスワップ：合計34989560k、使用済み0k、34989560k無料、5268548kキャッシュPIDユーザーPR NI VIRT RES SHR S％CPU％MEM TIME + COMMAND 31866 packrd 18 0 19.9g 12g 11m S 117.0 41.3 4：43.85 java 912 root 11-5 0 0 0 S 2.0 0.0 1：40.46 kjournald
したがって、アイドルCPU、0.0％waがたくさんありますが、平均負荷は非常に高いことがわかります。
 
iostatも同様に、ディスクを基本的にアイドル状態として表示します。
 
avg-cpu：％user％nice％system％iowait％steal％idle 9.62 0.00 8.75 0.00 0.00 81.62デバイス：rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz await svctm％util sda 0.00 49.00 0.00 6.40 0.00 221.60 69.25 0.01 0.81 0.66 0.42 sda1 0.00 49.00 0.00 6.40 0.00 221.60 69.25 0.01 0.81 0.66 0.42 sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.htmlも参照してください
 
補足として、これは（少なくともこの場合はCentOSを実行している）負荷平均に各スレッドが合計に個別に含まれていることも意味しているようです。
 
 
解決策4：解決策4：
 
今日も同じ問題がありました。いくつかの調査と診断の後、私は自分の小さなVPSが ディスクが不足しています 。
 
シェル/プロンプト（Linux / Unix）タイプ
 
df -h
見るために ディスクフリー あなたのマシンで。ディスクが不足している場合は、問題/問題である可能性があります。
 
 
解決策5：解決策5：
 
この状況で役立つもう1つの便利なツールはnmonです。
 
1つの小さなパッケージに、他のツールによって提示された同じデータを表示するさまざまな方法が含まれています。
 
これがキャッシュできないコンテンツである場合は、負荷を分散するために、tcpモードのhaproxyなどのロードバランサーの背後に複数のサーバーを配置することをお勧めします。