Sugestões necessárias para depurar porque o ps -ef fica preso

7

Alguns dos meus processos consomem 100% de CPU. Estou tentando descobrir quais scripts estão causando isso

Eu tentei executar strace ps -ef :

open("/proc/PID/status", O_RDONLY) = 6
read(6, "Name:\textract\nState:\tR (running)"..., 1023) = 1023
close(6) = 0
open("/proc/PID/cmdline", O_RDONLY) = 6
read(6,

Então fica preso tentando ler /proc/PID/cmdline . Eu tentei cat ting isso, e ficou preso novamente. Algo está obviamente enroscado no kernel; o que devo tentar em seguida?

Nota: a reinicialização não funciona - se eu desligar manualmente, o problema é iniciado novamente. Estou usando o SUSE Linux Enterprise Server 11 (x86_64), Linux 2.6.27.19

Editar : ps -e produz saída e descobri que há muitos grep s. O número de grep s varia: 250, 450 e agora vejo cerca de 520 greps. Eu segui e descobri que é o resultado de um script cron. Eu ainda tenho que entender esses scripts cron. Sim, top exibe resultados. Nós desligamos manualmente o servidor dois dias atrás. O sistema foi executado nos últimos 2 dias. Eu vejo algumas coisas do oracle correndo o tempo todo. Acabei de fazer o teste de memória, sem falhas detectadas

    
por 72616b657368 09.04.2011 / 23:09

2 respostas

1

Tivemos isso ontem mesmo. O problema era que um processo estava em estado "ininterrompível", mostrado como status D na parte superior. ls / proc / não retorna e não é abortável. ps -ef não retorna e não é abortável.

Se a reinicialização não ajudar, você provavelmente terá um setor defeituoso em seu DVD ou disco rígido e o processo que o PID está tentando ler durante a inicialização. Então, tecnicamente, a reinicialização ajuda, mas o erro ocorre novamente automaticamente.

Verifique com o topo se o processo está de fato no status D, e continue a partir daí. Inicialize o computador sem chamar esse processo (sistema de recuperação). Em seguida, inicie o programa aplicando-o e veja quais arquivos ele acessa. Aposto que um arquivo tem setores defeituosos.

    
por 18.01.2014 / 09:41
0

Parece que o grep está suspenso e, devido ao cronograma de trabalho do cron, outro processo se tornará ativo após certo período de tempo (conforme escrito no crontab). Múltiplos processos levarão um sistema sem resposta

Tente seguir o método de depuração:

  • Alterar a entrada crontab para aumentar o intervalo de script (para que o script de suspensão não seja executado muitas vezes)
  • Gravar saída do topo por um intervalo
  • Atravessar a árvore de processos dos principais registros e, em seguida, encontrar o processo no qual ela está sendo pendurada
  • Em seguida, percorra o código em que a mesma coisa está sendo chamada.
por 20.02.2014 / 13:50