高負荷平均、低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に関する良い説明はこちらをご覧ください。

私は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を待機しているスレッド/プロセスが負荷平均に表示されることがありますが、「await」列の増加は発生しないようです。しかし、それらはまだI / Oバウンドです。

jrubyで実行すると、次のコードがこれに該当することがわかります（それぞれ100個のスレッドで多くのI / Oを実行します）。

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

マシンの空きディスクを確認します。ディスクが不足している場合は、問題/問題である可能性があります。

この状況で役立つもう1つの便利なツールはnmonです。

他のツールで表示される同じデータを1つの小さなパッケージで表示するさまざまな方法が含まれています。

これがキャッシュできないコンテンツである場合は、負荷を分散するために、tcpモードのhaproxyなどのロードバランサーの背後に複数のサーバーを配置することをお勧めします。

これに加えて、このような問題のデバッグに役立つ、言及されていないSolaris固有のツールには、「intrstat」、「mpstat」、および「lockstat」があります。以前にいくつかの重いETLロードを実行しているホストで同様の問題を経験していたmpstatは、問題を示唆する大量のI / Oを処理する大量の割り込みを明らかにしました。

当時、mpstatを備えたT4-4では、vcpusが短い監視サイクルで30000を超える割り込みを処理し、その後パフォーマンスが低下し始めました。この場合、唯一の回避策はより多くのCPUを投入することでしたが、その後コードを改善するための作業が行われました。

Brendan Greggはパフォーマンス、特に長年にわたるI / Oについて多くのことを書いてきました。詳細については、検索する価値があります。