커널과 워치 독이 모든 CPU를 소비하는 이유는 무엇입니까?

강력한 Xeon 머신 (/ proc / cpuinfo에 따라 32 개의 가상 프로세서)에서 많은 사용자 공간 프로세스를 실행합니다. CPU로드는 일반적으로 약 30이고 기계는 반응을 느낍니다. 그러나 나중에 더 많은 사용자 공간 프로세스가 분기되고 많은 양의 메모리를 할당하고 CPU 집약적 인 계산을 수행합니다. 그 때 하중은 약 60-150으로 증가하고 기계는 무릎을 꿇습니다.

그러나 그 때 CPU가 내 사용자 공간 프로세스에서 더 이상 소비되지 않는 것처럼 보입니다. 아래의 출력을 참조하십시오.

질문 :

워치 독이 너무 많은 CPU를 소비하게하는 원인은 무엇입니까?

내 사용자 공간 프로세스 대신 93.1 %의 CPU가 시스템에서 소비되는 이유를 추측 할 수 있습니까?

top - 13:58:49 up 44 days,  6:32, 11 users,  load average: 137.97, 64.80, 30.74
Tasks: 403 total,  48 running, 355 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.4%us, 93.1%sy,  0.0%ni,  0.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    258441M total,   257793M used,      647M free,     3243M buffers
Swap:    16383M total,        0M used,    16383M free,   239114M cached

  PID USER      PR  NI  VIRT  RES  SHR S   %CPU %MEM    TIME+  COMMAND
53921 me        20   0 1380m  88m  10m S    333  0.0   0:59.21 java
   40 root      RT   0     0    0    0 S     97  0.0  34:43.65 watchdog/8
   68 root      RT   0     0    0    0 S     93  0.0  27:57.92 watchdog/15
   52 root      RT   0     0    0    0 S     92  0.0  27:49.83 watchdog/11
   88 root      RT   0     0    0    0 S     82  0.0  37:38.22 watchdog/20
54041 me        20   0 1317m  82m  10m S     78  0.0   1:00.55 java
   24 root      RT   0     0    0    0 S     67  0.0  30:50.30 watchdog/4
 3460 root      20   0     0    0    0 S     55  0.0   4:44.01 afs_rxevent
  128 root      RT   0     0    0    0 S     53  0.0  38:39.29 watchdog/30
45245 root      20   0     0    0    0 R     53  0.0   1:25.40 kworker/2:0
  124 root      RT   0     0    0    0 S     50  0.0  36:14.85 watchdog/29
42623 root      20   0     0    0    0 R     49  0.0   3:24.94 kworker/1:0
55884 foo       20   0 34640  20m 7796 R     49  0.0   0:05.64 program1
53312 me        20   0 1388m 191m  10m S     48  0.1   1:25.89 java
44111 root      20   0     0    0    0 R     47  0.0   5:12.84 kworker/24:0
   86 root      20   0     0    0    0 R     43  0.0  26:00.48 kworker/20:0
55968 foo       20   0 34660  20m 7800 R     38  0.0   0:03.16 program1
55562 foo       20   0  193m  14m 5264 S     38  0.0   0:02.45 program2
   26 root      20   0     0    0    0 R     37  0.0  35:39.29 kworker/5:0
  344 root      20   0     0    0    0 R     33  0.0  32:38.50 kworker/29:1

> uname -a
Linux machine5 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux

응용 프로그램이 시스템 호출 (예 : read (2))을 발행하면 시스템 호출에 걸린 시간은 사용자 공간이 아닌 % sy로 간주됩니다. 이상하게도 스왑 공간이 전혀 없습니다. 너는 그것을 무력화 시켰는가? 사용자가 설명하는 동작은 커널 메모리 조각화와 일치하며, 커널이 동적 메모리 할당을 수행하는 것을 더욱 어렵고 힘들게 만듭니다.

top (1) 출력에 의존하지 마십시오. 이런 일이 생기면 / proc / meminfo에서 진실을 찾으십시오. Committed_AS가 MemTotal에 근접하거나 초과하면 시스템에서 사용 가능한 메모리를 초과했으며 스와핑을 시작해야합니다. Committed_AS가 CommitLimit를 초과하면 실제 메모리와 스왑 공간이 모두 소모됩니다. 그러나이 지점에 도달하기 전에 설명 된 절벽과 같은 성능이 저하됩니다.