로드 평균이 높고 CPU 사용량이 적은 이유는 무엇입니까?

우리는 웹 응용 프로그램에서 큰 성능 문제를 발견하고 병목 현상을 찾으려고 노력하고 있습니다. 나는 sysadmin이 아니기 때문에 내가 얻지 못한 것들이 있습니다. 일부 기본 조사에 따르면 CPU가 유휴 상태이고, 사용 가능한 메모리가 많으며, 스와핑, I / O는 없지만 평균로드는 높습니다.

이 서버의 소프트웨어 스택은 다음과 같습니다.

• 솔라리스 10
• 자바 1.6
• WebLogic 10.3.5 (8 개 도메인)

이 서버에서 실행되는 응용 프로그램은 다른 서버의 Oracle 데이터베이스와 통신합니다.

이 서버에는 32GB의 RAM과 10 개의 CPU가 있습니다.

Running 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가 대부분 유휴 상태이지만 부하 평균이 높기 때문에 상당히 이상합니다. 메모리는 문제가되지 않는 것 같습니다.

Running 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

Running 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

내가 무엇을 놓치고 있습니까?

추가 조사를 통해 성능 문제는 주로 두 시스템 (Oracle SSXA 및 UCM) 간의 많은 네트워크 호출로 인한 것으로 보입니다. 호출은 빠르지 만 풍부하고 직렬화되므로 CPU 사용률 (대부분 I / O 대기),로드 평균 (처리 대기중인 많은 호출) 및 특히 긴 응답 시간 (작은 응답 시간 누적)이 길어집니다.

이 문제에 대한 귀하의 통찰에 감사드립니다!

'높은 부하 평균'이라고 말하면 prstat가 출력 수치의 맨 아래에 '부하 평균'을 표시한다고 가정합니다.

Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11

이 숫자는 최상위에서 제공하는 숫자와 유사하며 실행중인 프로세스의 평균 큐 크기를 의미합니다. 이것은 사용중인 프로세서 시간의 백분율이 아니라 실행 시간 동안 CPU를 괴롭히는 '사물'수입니다. 분명히, 이것들은 상당히 높아 보이지만 이것은 모두 실행중인 앱에 달려 있습니다. 프로세스는 슬롯을 확보 한 후에 실제로 많은 작업을 수행하지 않을 수 있습니다. 상단에 대한 좋은 설명 은 여기 를 참조 하십시오 .

나는 WebLogic에 익숙하지 않지만 일반적으로 Apache Tomcat을 사용하면 많은 요청으로 나타나지 않는 것에 대해 많은 Java 스레드가 동시에 생성 될 수 있음을 알았습니다. 이것이 평균로드 수를 높이는 원인 일 수 있습니다. 백엔드에 연결하기에 적절한 위치에서 연결 풀링을 사용하고 연결을 처리하기 위해 앱에서 사용할 수있는 유휴 스레드 수를 늘리십시오 (WebLogic에서이 작업을 수행하는 방법을 모르는 경우 Tomcat은 커넥터 당 스레드 풀 또는 일반 실행기 스레드 풀). 이 작업을 수행하지 않으면 요청을 처리하기 위해 새로운 스레드가 생성 될 수 있습니다.

성능 과 관련하여 앱의 어떤 부분이 어려움을 겪고 있는지 파악 해야합니다 . WebLogic / Java 측면에서 발생하는 처리, 데이터베이스 액세스, DNS 조회 (어떤 이유로 인해 수행되는 경우 ...), 네트워크 문제 또는 OS에서 발생하는 처리입니까?

99 %의 시간이 코드가되고 코드를 유지하는 데이터베이스와 통신하는 방법입니다. 그런 다음 웹앱의 구성이됩니다. 이 시점을 지나면 앱에서 마지막 밀리 초를 짜거나 동일한 하드웨어로 더 높은 동시성을 제공하는 작업을 수행하게됩니다. 이 세밀한 성능 조정을 위해서는 메트릭이 필요합니다.

Java의 경우 Java Melody 설치를 제안 합니다. 그것은 당신의 프로그램이 무엇을하고 있는지에 관한 많은 정보를 제공 할 수 있고, 시간을 소비하는 곳을 좁히는 데 도움이됩니다. Tomcat에서만 사용했지만 Java EE 컨테이너 / 서블릿과 잘 작동합니다.

Java를 튜닝 할 수있는 방법에는 여러 가지가 있으므로 성능 지침을 살펴보고 (아마도 가지고있을 것입니다) 프로그램에 적합한 힙 크기 등을 올바르게 설정했는지 확인하십시오. Java Melody를 사용하면 사용중인 Java 힙의 크기와 가비지 수집기의 작동 정도 / 개체를 삭제하기 위해 프로그램을 방해하는 빈도를 추적 할 수 있습니다.

도움이 되었기를 바랍니다. 더 자세한 정보를 제공하면이 답변을 업데이트하여 귀하의 필요에 맞게 더 자세히 설명 할 수 있습니다.

부수적으로,로드 평균에는 디스크 활동을 기다리는 것 (즉, 디스크를 괴롭히는 것)과 CPU를 기다리는 것들도 포함됩니다.이 둘의 합입니다.

참조 ) http://en.wikipedia.org/wiki/Load_(computing을 ") 리눅스가 [그 부하 평균]가 포함 일반적으로 디스크 활동을 기다리고 (무정전 절전 상태에서 처리"

부수적으로, 내가 겪었던 특정 문제는로드 평균이 높지만 유휴 CPU가 많고 디스크 사용량이 적다는 것입니다.

적어도 내 경우에는 때때로 입출력을 기다리는 스레드 / 프로세스가로드 평균에 표시되지만 "대기"열이 증가 하지는 않는 것 같습니다. 그러나 여전히 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

머신에 디스크 여유 공간 이 있는지 확인하십시오 . 디스크가 부족한 경우 문제 / 문제 일 수 있습니다.

이 상황에서 도움이되는 또 다른 유용한 도구는 nmon입니다.

하나의 작은 패키지로 다른 도구에서 제공하는 동일한 데이터를 볼 수있는 다양한 방법이 포함되어 있습니다.

캐시 할 수없는 컨텐츠 인 경우, tcp 모드에서 haproxy와 같은로드 밸런서 뒤에 여러 서버를 배치하여로드를 분배하는 것이 좋습니다.

여기에 언급되지 않은 이러한 문제를 디버깅하는 데 유용한 일부 Solaris 관련 도구는 "intrstat", "mpstat"및 "lockstat"입니다. 많은 ETL로드를 실행하는 호스트에서 비슷한 문제가 발생했던 mpstat mpstat는 많은 I / O를 처리하는 많은 양의 인터럽트가 문제를 암시하는 것으로 나타났습니다.

당시 mpstat를 사용하는 T4-4에서 짧은 모니터링주기 동안 vcpus가 30000 개 이상의 인터럽트를 처리 한 후 성능이 저하되기 시작했습니다. 이 경우 유일한 해결 방법은 더 많은 CPU를 사용하는 것이었지만 나중에 코드를 개선하기위한 작업이 수행되었습니다.

Brendan Gregg는 성능, 특히 수년 동안 I / O와 관련하여 많은 내용을 작성했으며 더 자세한 정보를 원한다면 검색 할 가치가 있습니다.