detecta processo comendo cpu sem: top, htop, ps?

Question

Eu passei por um problema em que só conseguia adivinhar qual processo estava comendo a CPU.

Meu uso da CPU foi de aproximadamente 80% para todos os núcleos no psensor.

Eu tentei htop , top e ps -A -o pcpu,pid,cmd --sort +pcpu (a última que eu tentei com o sudo, sem sucesso). Todos estes mostraram o culpado pid (que eu estava ciente) usando apenas cerca de 7% ...

Quando eu SIGKILL no pid, tudo volta ao normal.

Para testar, eu fiz um loop infinito no terminal while true;do echo -n;done mas que eu pude ver claramente no htop; então meu palpite o que estava causando problemas não foi semelhante a isso ...

Então, eu me pergunto se existem outras maneiras que eu poderia ter encontrado o culpado sem ter que adivinhar?

Pensando novamente, acho que gostaria de saber quais cálculos psensor e "applet indicador de carga do sistema" usam que puderam mostrar esse valor, mas os outros não conseguiram?

PS .: vinculando o tempo de espera , vinculação da média de carga

    

Answer 1

Não estou familiarizado o suficiente com os detalhes para fornecer dicas precisas, mas acho que há duas fontes de diferenças entre a carga real causada e o uso da CPU mostrado:

1. O processo pode consistir em vários encadeamentos e top pode não os resumir. Você pode ver o número de segmentos por isso:

   ps -eo pid,nlwp,%cpu,user,args
   

   Em top , você pode alternar o tratamento de segmentos com H . O uso da CPU de cada thread é geralmente muito baixo.

2. O processo pode causar muita E / S. O tempo de espera de E / S é parte da carga geral da CPU, mas pode não fazer parte do valor de uso da CPU de um processo. Portanto, verifique o valor wait em top . Ele não diz a você quais processos causam isso até que ponto, mas se o valor for baixo, não será possível explicar o efeito.

Answer 2

O código executado em um sistema unix é classificado como código do kernel ou código de usuário. O código de aterramento do usuário é sempre anexado a um processo, portanto, se a CPU estiver ocupada executando o código de aterramento do usuário, ele será exibido em alguma linha em top . O código do kernel é normalmente anexado a um processo: se o kernel está executando uma chamada de sistema, então o processamento no kernel é considerado como pertencente a esse processo. A hora do kernel é a "hora do sistema" informada pelo utilitário time .

Algumas das coisas que o kernel faz não podem ser diretamente contabilizadas em um processo. Em particular, as interrupções de hardware não pertencem intrinsecamente a um processo específico. Por exemplo, suponha que uma interrupção seja acionada pela placa de rede. O kernel executa código para ler e analisar o pacote de rede; até agora nenhum processo está envolvido. O pacote pode ser rejeitado por meio de uma regra de firewall, caso em que nenhum processo pode reivindicar esse tempo de processamento. Se um processo acabar recebendo esse pacote, parte do tempo de recepção será colocado na guia do processo, mas não nos estágios iniciais.

Portanto, é possível ter tempo de CPU que não pertence a nenhum processo. No entanto, às vezes, esse tempo de CPU é indiretamente causado por algum processo. Por exemplo, se há um processo que envia pacotes para outra máquina e faz com que essa outra máquina responda, mas o firewall bloqueia os pacotes de resposta, o tempo gasto analisando e descartando os pacotes de resposta não será rastreado até o processo de envio; mas se o processo de envio parar, o que faz com que a máquina remota pare de responder, o kernel não perderá tempo rejeitando mais os pacotes. Claro que a rede é apenas um exemplo, existem muitas outras maneiras para o kernel fazer coisas que não podem ser rastreadas diretamente em um processo.

Você não deu informações suficientes para ter certeza de que é isso que está acontecendo (e pode ser difícil descobrir sem um depurador de kernel), mas essa é uma explicação plausível.

    

Answer 3

Se não quiser usar o htop, ps, top, você pode usar o systemtap, para mais detalhes de baixo nível