Por que o kernel e os watchdogs estão consumindo toda a CPU?

Question

Eu corri um monte de pesados processos de espaço do usuário em uma poderosa máquina Xeon (32 processadores virtuais de acordo com / proc / cpuinfo). A carga da CPU é normalmente em torno de 30 e a máquina parece responsiva, mas mais tarde, mais alguns processos de espaço do usuário são bifurcados e alocam muita memória e executam cálculos intensivos da CPU. Nesse momento, a carga aumenta para cerca de 60-150 e a máquina está de joelhos.

Mas quando isso ocorre, a CPU não parece ser (principalmente) consumida pelos processos de espaço do usuário. Veja a saída do topo abaixo.

Perguntas:

O que pode fazer com que os watchdog consumam tanto CPU?

É possível adivinhar por que 93,1% da CPU é consumida pelo sistema, em vez de meus processos de espaço do usuário?

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

    

Answer 1

Quando o aplicativo emite uma chamada do sistema [como read (2)], o tempo gasto pela chamada do sistema é considerado como% sy, não como espaço do usuário. Estranho que você não tenha espaço de troca usado; você desativou isso? O comportamento que você descreve é consistente com a fragmentação da memória do kernel, o que torna o kernel mais difícil e difícil de executar a alocação dinâmica de memória que ele usa bastante.

Não confie na saída top (1); quando isso acontecer, procure em / proc / meminfo a verdade. Se Committed_AS se aproximar ou exceder o MemTotal, você excedeu a memória disponível no sistema e precisa começar a trocar. Se Committed_AS exceder CommitLimit, você esgotou a memória física e o espaço de troca. Antes de chegar a este ponto, no entanto, a performance cai sobre um penhasco como você descreveu.