Pode ser consumido pela CPU dentro de um processo de kernel, driver ou interrupções.
Esta não é uma resposta, mas uma maneira de abordar a solução. Alguns detalhes dessa abordagem são específicos do Linux. Instale o pacote sysstat aka sar e modifique ou adicione um crontab do sar-collection (em sistemas RedHat, /etc/cron.d/sysstat ):
* * * * * root /usr/lib64/sa/sa1 -L -F -S XALL 10 6
Esteja preparado para acumular 3 GB ou mais durante o mês em /var/lib/sa . Se a sua versão não suportar -L nem -F , adicione a seguinte entrada cron:
57 23 * * * root rm -f /var/log/sa/sa'date --date=tomorrow +\%d'
Após um dia, use sar -f /var/log/sa/saXX -C , em que XX é o dia do mês anterior de ontem como um número inteiro 0 (ou seja, 01, 02, ... 10, 11 ... 31). Quando você encontrar uma janela de tempo em que a CPU estava alta, você pode verificar o relatório do sar para essa janela de tempo para:
- interrupções (
-I ALL) - uso da rede (
-n DEV)
E / S de disco - (
-b)
Digamos que você veja o salto da CPU entre 10:15 e 10:18. Execute sar nesse dia (05) da seguinte forma:
sar -f /var/log/sa/sa05 -s 10:14:00 -e 10:19:00 -I ALL -n DEV -b | less
Adicionamos um minuto de cada lado para que você possa observar antes / durante / depois, não apenas durante.
Se você ainda não vê nada, e você já olhou para outros parâmetros do sar e você ainda não vê nada, tente adicionar isto ao cron:
* * * * * { date; /bin/ps -A --sort tty,comm,pid -ww -o pgrp:8,tty:7,pid,c,pmem:5,rss:8,sz:8,size:8=TSIZE,vsz:8,nlwp,lstart,args ;} >>/var/log/procscan
Esse arquivo vai ficar muito grande, então gire-o ou desative o cronjob no dia seguinte. Mas desta saída, você pode encontrar seu culpado.
Para resolver alguns dos problemas com este cronjob, criei um script wrapper e um conjunto de arquivos de suporte e os coloquei no github. Você pode encontrá-los aqui (link para o projeto no github)