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

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 6mostra 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 exposto, parece que algo deve estar sobrecarregado. Mas o que?

Questões

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?

Como ponto de esclarecimento, a carga não está diretamente ligada à CPU. Esse é um dos equívocos mais comuns sobre carga. O fato de você mencionar disco parece reconhecer que você está ciente disso, mas eu só queria mencionar isso, pois vejo comentários que indicam alguns que acreditam de outra forma.

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

Para descobrir quais processos são um problema:

Executar top -H( -Hhabilita a exibição de threads)

Os atalhos do teclado variam de acordo com a versão.

Com a parte superior mais recente (3.3 e posterior):

Pressione fpara exibir as opções de campo.
Use as setas do teclado para acessar S = Process Statuse pressionar s.
Pressione qpara voltar à página principal.
Pressione Shift+ Rpara reverter a classificação.

Com o topo mais antigo (antes do 3.3):

Pressione Shift+ opara exibir as opções de classificação.
Depois, wpara classificar por status do processo.
Depois, Entervolte à página principal.
Então Shift+ Rpara reverter a classificação.

Em seguida, na Scoluna, procure processos que possuem Dou R(agora devem estar no topo). Estes serão processos que contribuem para a carga do sistema.

Se o processo mostrar um D, isso significa "suspensão ininterrupta". Geralmente, isso é causado quando o processo está aguardando na E / S (disco, rede etc.).
Se o processo mostra a R, isso significa que está apenas fazendo o cálculo normal.

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

Com a parte superior mais recente (3.3 e posterior):

Pressione fpara exibir as opções de campo.
Use as teclas de seta para acessar WCHAN = Sleeping in Functione pressione dpara habilitá-lo.
Depois, qvolte à página principal.

Com o topo mais antigo (antes do 3.3):

Pressione fentão ypara ativar o WCHANcampo.

Se o seu sistema possui as opções necessárias do kernel e o arquivo wchan está presente no sistema (eu esqueço onde ele está e como é chamado) , o WCHANcampo deve mostrar qual função do kernel o processo está executando no momento (se o campo mostrar apenas um -ou ?em tudo, você não tem suporte).
Um pouco do google aqui e você deve estar no seu caminho.

Se você não tem suporte, sempre pode experimentar straceos processos para descobrir o que eles estão fazendo, mas essa é a maneira mais difícil.

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

Nesses casos, o Linux Audit Framework ajudará

O culpado, um loop de falha, 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 do log todos os lançamentos do processo

Eu tive uma situação em que as montagens NFS foram desconectadas e, infelizmente, cometi um erro e não usei a opção de montagem suave, portanto, muitos processos foram afetados no meu servidor Linux, incluindo monitoramento, lsof e até sessões bash ....

Após desmontar montagens quebradas, o sistema parecia sobrecarregado:

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

Isso parecia terrível, mas o uso da CPU era inferior a 15% e não há E / S de disco. Eu recebi alguns conselhos para analisar o ps, mas isso não ajudou, pois parecia que os processos estão na maior parte adormecidos.

Em seguida, man pssalvei minha noite para dormir e, após a investigação, encontrei sinalizadores de STATUS muito importantes, pois depois identificamos que eram processos emperrados .

Executar:

ps -e v

e procure processos que tenham Dou SLna coluna STAT. Estes eram como processos de zumbis, mas não identificados como z-zumbis.

D - significa principalmente atividade de disco (E / S), mas também se você executar ps -e valgumas vezes e também iostat 3e não vir nenhuma atividade, isso indicou que a E / S está presa .

SL - isso significa que há páginas bloqueadas na memória desse processo; portanto, se você puder identificar que esse processo não deve se comportar assim, será o próximo candidato possível se ele permanecer por um longo período sem alterações.

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