Uso da CPU no Linux e histórico de execução do processo

35

Existe alguma maneira de ver quais processos causaram mais uso da CPU?

Eu tenho o AMAZON EC2 Linux, cuja utilização da CPU chega a 100% e me faz reiniciar o sistema. Eu não consigo nem fazer o login através do SSH (usando putty).

Existe alguma maneira de ver o que causa um uso tão alto da CPU e qual processo causou isso?

Eu sei sobre o comando sar e top , mas não consegui encontrar o histórico de execução do processo em nenhum lugar. Aqui está a imagem da ferramenta de monitoramento do Amazon EC2, mas gostaria de saber qual processo causou isso:

Eu também tentei ps -eo pcpu,args | sort -k 1 -r | head -100 , mas não tive sorte em encontrar um uso tão alto da CPU.

    
por PMoubed 08.05.2012 / 23:17

4 respostas

34

Existem algumas maneiras possíveis de fazer isso. Note que é totalmente possível que seus muitos processos em um cenário desenfreado causem isso, não apenas um.

A primeira maneira é configurar o pidstat para ser executado em segundo plano e produzir dados.

pidstat -u 600 >/var/log/pidstats.log & disown $!

Isso lhe dará uma perspectiva bastante detalhada do funcionamento do sistema em intervalos de dez minutos. Eu sugiro que este seja seu primeiro porto de escala, pois ele produz os dados mais valiosos / confiáveis para se trabalhar.

Existe um problema com isso, principalmente se a caixa entrar em um loop de cpu descontrolado e produzir uma carga enorme - não é garantido que o processo real será executado de maneira oportuna durante a carga (se necessário) para que você possa realmente perca a saída!

A segunda maneira de procurar isso é habilitar a contabilidade do processo. Possivelmente mais uma opção a longo prazo.

accton on

Isso ativará a contabilização do processo (se ainda não tiver sido adicionado). Se não estava sendo executado, isso precisará de tempo para ser executado.

Tendo sido executado, por exemplo, 24 horas - você pode executar esse comando (o que produzirá uma saída como essa)

# sa --percentages --separate-times
     108  100.00%       7.84re  100.00%       0.00u  100.00%       0.00s  100.00%         0avio     19803k
       2    1.85%       0.00re    0.05%       0.00u   75.00%       0.00s    0.00%         0avio     29328k   troff
       2    1.85%       0.37re    4.73%       0.00u   25.00%       0.00s   44.44%         0avio     29632k   man
       7    6.48%       0.00re    0.01%       0.00u    0.00%       0.00s   44.44%         0avio     28400k   ps
       4    3.70%       0.00re    0.02%       0.00u    0.00%       0.00s   11.11%         0avio      9753k   ***other*
      26   24.07%       0.08re    1.01%       0.00u    0.00%       0.00s    0.00%         0avio      1130k   sa
      14   12.96%       0.00re    0.01%       0.00u    0.00%       0.00s    0.00%         0avio     28544k   ksmtuned*
      14   12.96%       0.00re    0.01%       0.00u    0.00%       0.00s    0.00%         0avio     28096k   awk
      14   12.96%       0.00re    0.01%       0.00u    0.00%       0.00s    0.00%         0avio     29623k   man*
       7    6.48%       7.00re   89.26%       0.00u    0.00%       0.00s    

As colunas são ordenadas como tal:

  1. Número de chamadas
  2. Porcentagem de chamadas
  3. Quantidade de tempo real gasto em todos os processos desse tipo.
  4. Porcentagem
  5. Tempo de CPU do usuário
  6. Porcentagem
  7. Tempo de CPU do sistema.
  8. Chamadas médias de IO.
  9. Porcentagem
  10. Nome do comando

O que você está procurando são os tipos de processos que geram mais tempo de CPU do usuário / sistema.

Isso divide os dados como a quantidade total de tempo de CPU (a linha superior) e, em seguida, como esse tempo de CPU foi dividido. O processo de contabilizar somente as contas corretamente quando está ligado quando os processos são gerados, então é melhor reiniciar o sistema depois de habilitá-lo para garantir que todos os serviços estejam sendo contabilizados.

Isso, na verdade, não lhe dá uma idéia definitiva do processo que pode ser a causa desse problema, mas pode lhe dar uma boa impressão. Como poderia ser um instantâneo de 24 horas, há uma possibilidade de resultados distorcidos, então tenha isso em mente. Ele também deve sempre ser registrado, já que é um recurso do kernel e, diferentemente do pidstat, sempre produzirá a saída mesmo durante uma carga pesada.

A última opção disponível também usa contabilidade de processo para que você possa ativá-la como acima, mas depois usar o programa "lastcomm" para produzir algumas estatísticas de processos executados no momento do problema, juntamente com estatísticas de CPU para cada processo. / p>

lastcomm | grep "May  8 22:[01234]"
kworker/1:0       F    root     __         0.00 secs Tue May  8 22:20
sleep                  root     __         0.00 secs Tue May  8 22:49
sa                     root     pts/0      0.00 secs Tue May  8 22:49
sa                     root     pts/0      0.00 secs Tue May  8 22:49
sa                   X root     pts/0      0.00 secs Tue May  8 22:49
ksmtuned          F    root     __         0.00 secs Tue May  8 22:49
awk                    root     __         0.00 secs Tue May  8 22:49

Isso pode lhe dar algumas dicas também sobre o que pode estar causando o problema.

    
por 09.05.2012 / 00:14
17

O Atop é um daemon particularmente útil para analisar os detalhamentos até o nível do processo e, por padrão, arquiva esses dados por 28 dias. Além de apresentar uma incrível interface de monitoramento em tempo real, você pode especificar esses arquivos de log para abri-los e percorrê-los.

O artigo dá uma ideia das capacidades, e você pode encontrar mais no manpage .

É realmente um maravilhoso software.

    
por 09.05.2012 / 02:11
0

Uma solução é escrever um script que é executado através de um minuto cron ou em um loop de sono e envia um e-mail / scp job / dump para um volume ebs ... com saída relevante (dmesg, pstree -pa e ps aux, provavelmente vmstat) no instante em que encontrar a média de carga acima de um certo limite ...

    
por 09.05.2012 / 00:53