負荷平均が高く、CPU使用率が低い-なぜですか？
Webアプリケーションで大きなパフォーマンスの問題が発生し、ボトルネックを見つけようとしています。私はシステム管理者ではないので、取得できないものがあります。いくつかの基本的な調査では、CPUがアイドル状態であり、大量のメモリが利用可能であり、スワッピングがなく、I/Oがありませんが、平均負荷が高いことが示されています。
このサーバーのソフトウェアスタックは次のようになります。
- Solaris 10
- Java 1.6
- WebLogic 10.3.5（8ドメイン）
このサーバーで実行されているアプリケーションは、別のサーバー上のOracleデータベースと通信します。
このサーバーには32GBのRAM=と10個のCPUが搭載されていると思います）。
ランニング prstat -Zは次のようなものを提供します。
PID USERNAME SIZE RSS STATE PRI Nice TIME CPU PROCESS/NLWP
3836 ducm0101 2119M 2074M cpu348 58 0 8:41:56 0.5% Java/225
24196 ducm0101 1974M 1910M sleep 59 0 4:04:33 0.4% Java/209
6765 ducm0102 1580M 1513M cpu330 1 0 1:21:48 0.1% Java/291
16922 ducm0102 2115M 1961M sleep 58 0 6:37:08 0.0% Java/193
18048 root 3048K 2440K sleep 59 0 0:06:02 0.0% sa_comm/4
26619 ducm0101 2588M 2368M sleep 59 0 8:21:17 0.0% Java/231
19904 ducm0104 1713M 1390M sleep 59 0 1:15:29 0.0% Java/151
27809 ducm0102 1547M 1426M sleep 59 0 0:38:19 0.0% Java/186
2409 root 15M 11M sleep 59 0 0:00:00 0.0% pkgserv/3
27204 root 58M 54M sleep 59 0 9:11:38 0.0% stat_daemon/1
27256 root 12M 8312K sleep 59 0 7:16:40 0.0% kux_vmstat/1
29367 root 297M 286M sleep 59 0 11:02:13 0.0% dsmc/2
22128 root 13M 6768K sleep 59 0 0:10:51 0.0% sendmail/1
22133 smmsp 13M 1144K sleep 59 0 0:01:22 0.0% sendmail/1
22003 root 5896K 240K sleep 59 0 0:00:01 0.0% automountd/2
22074 root 4776K 1992K sleep 59 0 0:00:19 0.0% sshd/1
22005 root 6184K 2728K sleep 59 0 0:00:31 0.0% automountd/2
27201 root 6248K 344K sleep 59 0 0:00:01 0.0% mount_stat/1
20964 root 2912K 160K sleep 59 0 0:00:01 0.0% ttymon/1
20947 root 1784K 864K sleep 59 0 0:02:22 0.0% utmpd/1
20900 root 3048K 608K sleep 59 0 0:00:03 0.0% ttymon/1
20979 root 77M 18M sleep 59 0 0:14:13 0.0% inetd/4
20849 daemon 2856K 864K sleep 59 0 0:00:03 0.0% lockd/2
17794 root 80M 1232K sleep 59 0 0:06:19 0.0% svc.startd/12
17645 root 3080K 728K sleep 59 0 0:00:12 0.0% init/1
17849 root 13M 6800K sleep 59 0 0:13:04 0.0% svc.configd/15
20213 root 84M 81M sleep 59 0 0:47:17 0.0% nscd/46
20871 root 2568K 600K sleep 59 0 0:00:04 0.0% sac/1
3683 ducm0101 1904K 1640K sleep 56 0 0:00:00 0.0% startWebLogic.s/1
23937 ducm0101 1904K 1640K sleep 59 0 0:00:00 0.0% startWebLogic.s/1
20766 daemon 5328K 1536K sleep 59 0 0:00:36 0.0% nfsmapid/3
20141 daemon 5968K 3520K sleep 59 0 0:01:14 0.0% kcfd/4
20093 ducm0101 2000K 376K sleep 59 0 0:00:01 0.0% pfksh/1
20797 daemon 3256K 240K sleep 59 0 0:00:01 0.0% statd/1
6181 root 4864K 2872K sleep 59 0 0:01:34 0.0% syslogd/17
7220 ducm0104 1268M 1101M sleep 59 0 0:36:35 0.0% Java/138
27597 ducm0102 1904K 1640K sleep 59 0 0:00:00 0.0% startWebLogic.s/1
27867 root 37M 4568K sleep 59 0 0:13:56 0.0% kcawd/7
12685 ducm0101 4080K 208K sleep 59 0 0:00:01 0.0% vncconfig/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
42 135 22G 19G 59% 87:27:59 1.2% dsuniucm01
Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11
CPUはほとんどアイドル状態であると理解していますが、負荷平均が高く、これは私にはかなり奇妙です。メモリは問題ではないようです。
ランニング vmstat 15は次のようなものを提供します。
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s4 sd in sy cs us sy id
0 0 0 32531400 105702272 317 1052 126 0 0 0 0 13 13 -0 8 9602 107680 10964 1 1 98
0 0 0 15053368 95930224 411 2323 0 0 0 0 0 0 0 0 0 23207 47679 29958 3 2 95
0 0 0 14498568 95801960 3072 3583 0 2 2 0 0 3 3 0 21 22648 66367 28587 4 4 92
0 0 0 14343008 95656752 3080 2857 0 0 0 0 0 3 3 0 18 22338 44374 29085 3 4 94
0 0 0 14646016 95485472 1726 3306 0 0 0 0 0 0 0 0 0 24702 47499 33034 3 3 94
CPUはほとんどアイドル状態で、実行を待機しているプロセスはなく、スワッピングはほとんど行われていないことを理解しています。
ランニング iostat 15これを与える：
tty sd0 sd1 sd4 ssd0 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id
0 676 324 13 8 322 13 8 0 0 0 159 8 0 1 1 0 98
1 1385 0 0 0 0 0 0 0 0 0 0 0 0 3 4 0 94
0 584 89 6 24 89 6 25 0 0 0 332 19 0 2 1 0 97
0 296 0 0 0 0 0 0 0 0 0 0 0 0 2 2 0 97
1 1290 43 5 24 43 5 22 0 0 0 297 20 1 3 3 0 94
ランニング netstat -i 15は以下を提供します：
input aggr26 output input (Total) output
packets errs packets errs colls packets errs packets errs colls
1500233798 0 1489316495 0 0 3608008314 0 3586173708 0 0
10646 0 10234 0 0 26206 0 25382 0 0
11227 0 10670 0 0 28562 0 27448 0 0
10353 0 9998 0 0 29117 0 28418 0 0
11443 0 12003 0 0 30385 0 31494 0 0
何が欠けていますか？
さらに調査したところ、パフォーマンスの問題は主に、2つのシステム（Oracle SSXAとUCM）間のネットワーク呼び出しの数が多いことが原因であると思われます。呼び出しは高速ですが十分であり、シリアル化されているため、CPU使用率が低く（ほとんどがI/Oを待機しています）、負荷平均が高く（多くの呼び出しが処理されるのを待機しています）、特に長い応答時間（短い応答時間の累積による）です。
この問題についての洞察をありがとう！
「高負荷平均」と言ったとき、prstatは、出力値の下部にある「負荷平均」を示していると思います。
Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11
これらの数値は、topが提供する数値に似ており、おそらく実行中のプロセスの平均キューサイズを意味します。これは、使用されているプロセッサ時間の割合ではありませんが、実行するためにCPUを悩ませている「もの」の数です。確かに、これらはかなり高く見えますが、これはすべて、実行しているアプリに依存します。プロセスがスロットを取得した後は、実際には多くの処理を行っていない可能性があります。 topに関する素敵な説明は here を参照してください。
私はWebLogicに精通していませんが、一般に、Apache Tomcatでは、多くのJavaスレッドが、あまり多くないリクエストとして表示されるスレッドに対して同時に生成される可能性があります。これが原因となっている可能性があります。高い平均負荷数。バックエンドへの接続に適切な場所で接続プールを使用していることを確認し、接続を処理するためにアプリで使用できるアイドルスレッドの数を増やすことを検討してください（WebLogicでこれを行う方法は不明です。Tomcatにはコネクタスレッドプールまたは一般的なエグゼキュータスレッドプールごと）これを行わないと、リクエストを処理するために新しいスレッドが生成される場合があります。
パフォーマンスに関しては、アプリの一部を特定する必要があります。それは、WebLogic/Java側で発生している処理、データベースアクセス、DNSルックアップ（なんらかの理由で行われている場合）、ネットワークの問題、またはOS上の何かですか。
99％の確率で、それはあなたのコードであり、それが物事を妨げているデータベースとどのように通信するかです。次に、Webアプリの構成になります。この時点を過ぎると、アプリから最後の数ミリ秒をスクイーズするか、同じハードウェアでより高い同時実行性を提供することを検討することになります。このきめ細かいパフォーマンス調整には、メトリックが必要です。
Javaをインストールすることをお勧めします Java Melody です。これは、プログラムの動作に関する多くの情報を提供し、どこで時間を費やしているかを絞り込むのに役立ちます。私はこれはTomcatでのみ使用しましたが、Java EEコンテナー/サーブレットのもので問題なく動作するはずです。
Javaを調整する方法はいくつかあります。そのため、パフォーマンスガイドライン（おそらくそうだと思います）を確認し、プログラムに適した正しいヒープサイズなどを設定していることを確認してください。 Java Melodyは、消費しているJavaのヒープのサイズ、およびガベージコレクターの動作がどれだけ難しいか、オブジェクトをクリアするためにプログラムを中断する頻度を追跡するのに役立ちます。
お役に立てば幸いです。さらに情報を提供していただければ、この回答を更新し、お客様のニーズに合わせて改善できる可能性があります。
補足として、負荷平均には、ディスクアクティビティ（ディスクへの嫌がらせなど）を待機しているものだけでなく、CPUを待機しているものも含まれます。これは両方の合計です。したがって、どちらかで問題が発生する可能性があります。
http://en.wikipedia.org/wiki/Load_（computing） を参照してください。「Linuxには、[負荷平均に]割り込み不可能なスリープ状態のプロセスも含まれています（通常、ディスクアクティビティを待機しています）。
補足として、私が遭遇した特定の問題は、平均負荷が高いだけでなく、アイドル状態のCPUが多く、ディスク使用率が低いことでした。
少なくとも私の場合、I/Oを待機しているスレッド/プロセスが負荷平均に表示されることがありますが、しないと増加が発生するようです「待機」列。しかし、それらはまだI/Oバウンドです。
これがjrubyで実行する場合、次のコードの場合に当てはまることがわかります（多くのI/Oで100スレッドを実行するだけです）。
100.times { Thread.new { loop { File.open('big', 'w') do |f| f.seek 10_000_000_000; f.puts 'a'; end}}}
これはこのようなトップ出力を与えます：
top - 17:45:32 up 38 days, 2:13, 3 users, load average: 95.18, 50.29, 23.83
Tasks: 181 total, 1 running, 180 sleeping, 0 stopped, 0 zombie
Cpu(s): 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 total, 23239012k used, 9701892k free, 983644k buffers
Swap: 34989560k total, 0k used, 34989560k free, 5268548k cached
PID USER 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
Device: rrqm/s wrqm/s r/s w/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を実行している）負荷平均に各スレッドが合計で個別に含まれることも意味するようです。
今日も同じ問題がありました。いくつかの調査と診断の後、私の小さなVPSはディスク不足であることに気付きました。
シェル/プロンプト（Linux/Unix）タイプ
df -h
お使いのマシンでdisk freeを確認します。ディスクが不足している場合は、問題または問題である可能性があります。
この状況で役立つもう1つの便利なツールはnmonです。
他のツールで表示された同じデータを1つの小さなパッケージで表示するさまざまな方法が含まれています。
これがキャッシュできないコンテンツである場合、haproxyなどのロードバランサーの背後に複数のサーバーをtcpモードで配置して、負荷を分散することをお勧めします。
これに追加するために、そのような問題のデバッグに役立つ、言及されていないSolaris固有のツールには、「intrstat」、「mpstat」、「lockstat」があります。いくつかの重いETLロードを実行しているホストで以前に同様の問題を経験したことがあるmpstatは、問題を示唆する大量のI/Oを処理する大量の割り込みを明らかにしました。
当時、mpstatを使用したT4-4では、短い監視サイクルでvcpusが30000を超える割り込みを処理しており、その後パフォーマンスが低下し始めました。この場合の唯一の回避策は、CPUを増やすことでしたが、その後、コードを改善するための作業が行われました。
Brendan Greggはパフォーマンス、特に長年のI/Oについて多くのことを書いてきました。