Por que a carga é alta apesar do fato de que nem a CPU nem o disco são usados em excesso

Question

Estou recebendo a seguinte saída de top :

Cpu(s): 43.8%us, 32.5%sy,  4.8%ni,  2.0%id, 15.6%wa,  0.2%hi,  1.2%si,  0.0%st
Mem:  16331504k total, 15759412k used,   572092k free,  4575980k buffers
Swap:  4194296k total,   260644k used,  3933652k free,  1588044k cached

a saída de iostat -xk 6 mostra o seguinte:

Device: rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda       0.00   360.20   86.20  153.40  1133.60  2054.40    26.61     1.51    6.27   0.77  18.38
sdb       0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdd      22.60   198.80   17.40   31.60   265.60   921.60    48.46     0.18    3.70   1.67   8.20
sdc      16.80   218.20   22.20   23.40   261.60   966.40    53.86     0.21    4.56   1.49   6.78

Com base no acima, parece que algo deve estar sobrecarregado. Mas o que?

Perguntas

1. Se não é o disco rígido ou a CPU, então o que?
2. Parece que 15,6% do tempo da CPU é gasto em espera. O que exatamente poderia estar esperando?

Answer 1

Como ponto de esclarecimento, a carga não está diretamente ligada à CPU. Este é um dos equívocos mais comuns sobre carga. O fato de você mencionar o disco parece reconhecer que você está ciente disso, mas eu só queria mencioná-lo quando vejo comentários que indicam que alguns acreditam no contrário.

O carregamento é definido como o número de processos aguardando recursos do sistema. Isso geralmente é CPU, disco ou rede, mas pode ser qualquer coisa de hardware.
Um "processo" também não é necessariamente um processo completo. Um encadeamento é definido como um "processo leve", e cada encadeamento aguardando aumenta a contagem de carga.

Para descobrir quais processos são um problema:

Executar top -H (o -H permite mostrar segmentos)

Os atalhos de teclado variam por versão.

Com o novo topo (3.3 e depois):

Pressione f para exibir as opções de campo.
Use as teclas de seta para ir para S = Process Status e pressione s .
Pressione q para voltar à página principal.
Pressione Shift + R para inverter a classificação.

Com o topo mais antigo (antes de 3.3):

Pressione Shift + o para abrir as opções de classificação.
Então w para classificar pelo status do processo.
Então Digite para voltar para a página principal.
Então Shift + R para reverter a classificação.

Em seguida, na coluna S , procure por processos que tenham D ou R (agora eles devem estar no topo). Estes serão processos que contribuem para o carregamento do sistema.

Se o processo mostrar um D , isso significa "ininterrupto sleep". Geralmente isso é causado quando o processo está esperando na E / S (disco, rede, etc).
Se o processo mostrar um R , isso significa que está apenas fazendo computação normal.

Para saber mais sobre o que esses processos estão fazendo:

Com o novo topo (3.3 e depois):

Pressione f para exibir as opções de campo.
Use as teclas de seta para ir para WCHAN = Sleeping in Function e pressione d para ativá-lo.
Então q para voltar para a página principal.

Com o topo mais antigo (antes de 3.3):

Pressione f e y para ativar o campo WCHAN .

Se o seu sistema tiver as opções de kernel necessárias e o arquivo wchan estiver presente em seu sistema (eu esqueci onde está e como é chamado) , o campo WCHAN deve mostrar o kernel função que o processo está executando atualmente (se o campo mostrar apenas - ou ? em tudo, você não tem suporte). Um pouco de google aqui e você deve estar no seu caminho.

Se você não tem suporte, você pode sempre tentar um strace nos processos para descobrir o que eles estão fazendo, mas essa é a maneira difícil.

    

Answer 2

Processos de curta duração, como a compilação de trabalhos ou a falha de processos em um loop, geralmente não são visíveis em ferramentas de monitoramento como top ou iostat e assim por diante.

Em tais casos, o Linux Audit Framework ajudará

O culpado, um loop de falhas, por exemplo

while :; do gcc /dev/zero ; done >/dev/null 2>&1

Para usar o auditd / auditctl:

apt-get install auditd
auditctl -a task,always
ausearch -i -sc execve

roubado de registrar todos os lançamentos de processos

    

Answer 3

Eu tive uma situação quando o NFS montou desconectado e infelizmente cometi um erro e não usei a opção soft mount, assim muitos processos foram executados no meu servidor Linux, incluindo sessões de monitoramento, lsof e até bash ....

Depois de desmontar montagens quebradas, o sistema parecia sobrecarregado:

top - 00:03:48 up 15 days, 14:56,  3 users,  load average: 29, 21, 20

Isso parece terrível, mas o uso da CPU está abaixo de 15% e não há E / S de disco. Eu tenho alguns conselhos para passar por ps, mas isso não ajudou, uma vez que parecia que os processos estão na maior parte do sono.

Em seguida, man ps salvou minha noite de sono e, após a investigação, encontrei sinalizadores STATUS muito importantes para analisar, pois mais tarde identificaram que eles estavam emperrados .

Executar:

ps -e v

e procure por processos que tenham D ou SL na coluna STAT. Estes eram como processos zumbis, mas não identificados como zumbis.

D - significa principalmente atividade de disco (E / S), mas também se você executar ps -e v poucas vezes e também iostat 3 e não visualizar atividade, isso indica que isso é preso i / o .

SL - isso significa que existem Locked paginados na memória desse processo, portanto, se você puder identificar que esse processo não deve se comportar assim, ele será o próximo candidato possível se persistir por um período maior sem alteração.

Após a investigação, eu então matei um por um, e minha média de carga do sistema se tornou normal.