Enorme carga de CPU devido ao alto uso do sistema

Question

Tasks: 747 total, 176 running, 560 sleeping,   0 stopped,  11 zombie
Cpu(s): 10.5%us, 89.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:  74236420k total, 73285344k used,   951076k free, 12261184k buffers
Swap:  8388600k total,    10404k used,  8378196k free, 27872176k cached

89% da CPU está sendo usada por% sy. O que é isso% sy?

É assim que parecem os iostats

root@host [~]# iostat -xk 5
Linux 2.6.32-431.20.3.el6.x86_64 (host.superhostsite.com)       09/03/2014      _x86_64_        (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          43.02    0.28   50.00    0.05    0.00    6.65

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdb               0.25    64.95   14.21   79.82    91.86   579.51    14.28     0.15    1.60   0.09   0.84
sda               0.87   182.70   28.06  206.05   247.08  1629.10    16.03     0.49    2.07   0.09   2.22

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.45    0.00   91.55    0.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdb               0.00    14.00    0.20   15.00     3.20   116.00    15.68     0.03    1.92   0.28   0.42
sda               0.00    23.20    2.00   47.80    25.60   284.00    12.43     0.02    0.42   0.14   0.70

Portanto, o uso do disco é pequeno. Tudo é pequeno. E ainda, enorme 89,2% cpu usado pelo sistema.

Por que% sy é alto? Por que não% de nós?

    

Answer 1

Eu assumo que sua pergunta é basicamente "O que está acontecendo aqui?".

Eu responderei explicando sua saída - Se isso ajudar, me avise, adicionarei mais detalhes.
(Tente editar a questão para que fique mais claro o que você está pedindo, caso contrário, pode ser fechado)

Então, sim, você vê "uma carga enorme de CPU devido ao alto uso da CPU "!

Vamos ver a saída principal:

Cpu(s): 10.5%us, 89.2%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st

Os valores percentuais dizem onde o tempo é gasto - no código do usuário ou no código do sistema (kernel). O %sy é o tempo no código do sistema - e há 10% adicionais - o tempo do usuário. Então a CPU é usada por 100%! (Você pode vê-lo do 0% id - ocioso - também.)

Mas ainda há mais:

Tasks: 747 total, 176 running, 560 sleeping, 0 stopped, 11 zombie

Existem 176 processos em execução. Mas se você tiver menos de 176 núcleos, alguns deles estarão no estado em que poderiam executar se tivessem tempo de CPU. Isso significa que você tem mais carga, o que poderia levar mais CPUs a 100% de uso.
Sua CPU não está acostumada a 89,2% - é 100%

A partir disso, não há motivo para consultar iostat - o sistema não precisa de muito ES nesse estado.

Mas as informações de que precisamos: quais são esses, pelo menos, 176 processos ou threads, pode haver muitas outras tarefas semelhantes que não estão em execução.

E o próximo será: o que eles estão fazendo e por quê?

Então, dê uma olhada na lista de processos em top - isso pode mostrar algum problema óbvio.

Poderia ajudar a saber mais sobre os processos em estado "executável"; O comando abaixo lista todos os processos e threads que estão no estado "executável" - as tarefas que podem ser executadas se obtiverem tempo de CPU:

ps -o comm,pid,ppid,user,time,etime,start,pcpu,state --sort=comm aH | grep '^COMMAND\|R$'

Para mim, isso lista apenas uma ou duas linhas, incluindo ps em si

    

Answer 2

Eu posso ver na saída superior que há alta utilização de memória (incluindo o cache do sistema de arquivos enorme). Como dito, seu código do kernel está mais em uso do que o código do usuário, isso pode ser porque mais kworkers estão trabalhando para liberar a memória do cache e alocá-la para requisitar processos (o processo em execução 176 pode solicitar memória em tempo de execução).

Uma solução pode ser reduzir o tamanho do cache ou eliminá-lo usando:

echo 3 > / proc / sys / vm / drop_caches

Isso reduzirá o número de kworkers e, eventualmente, reduzirá a execução do código do kernel.