Eu tenho uma estação de trabalho RHEL5 que recentemente começou a "soluçar". A cada trinta segundos, aparentemente, interrompe completamente a execução por cerca de 4 segundos. Aparentemente nada é executado durante esse período. Os processos de longo prazo parecem alcançar sua entrada, mas novos processos simplesmente não são iniciados.
Exemplos concretos:
Eu tenho esse loop em execução em um shell:
while date; do
sleep 0.2
done
A saída simplesmente pula os segundos que faltam:
Fri Aug 13 15:20:29 EDT 2010
Fri Aug 13 15:20:29 EDT 2010
Fri Aug 13 15:20:29 EDT 2010
Fri Aug 13 15:20:30 EDT 2010
Fri Aug 13 15:20:30 EDT 2010
Fri Aug 13 15:20:30 EDT 2010
Fri Aug 13 15:20:30 EDT 2010
Fri Aug 13 15:20:34 EDT 2010
Fri Aug 13 15:20:34 EDT 2010
Fri Aug 13 15:20:35 EDT 2010
Fri Aug 13 15:20:35 EDT 2010
Fri Aug 13 15:20:35 EDT 2010
Se estiver digitando em um terminal, seja console local ou remoto via ssh ou telnet, o echoback faz uma pausa durante o tempo sem resposta, mas recupera quando começa a responder novamente, aparentemente sem perda de entrada, apenas lag. / p>
ping s fica sem resposta durante o tempo sem resposta, mas é respondido quando volta:
64 bytes from xxx: icmp_seq=1911 ttl=64 time=0.203 ms
64 bytes from xxx: icmp_seq=1912 ttl=64 time=0.199 ms
64 bytes from xxx: icmp_seq=1913 ttl=64 time=3202 ms
64 bytes from xxx: icmp_seq=1914 ttl=64 time=2196 ms
64 bytes from xxx: icmp_seq=1915 ttl=64 time=1197 ms
64 bytes from xxx: icmp_seq=1916 ttl=64 time=195 ms
64 bytes from xxx: icmp_seq=1917 ttl=64 time=0.201 ms
64 bytes from xxx: icmp_seq=1918 ttl=64 time=0.206 ms
Isso parece implicar que, na verdade, ele está recebendo dados durante o período que não responde, já que esses pacotes ICMP não estão sendo retransmitidos.
vmstat 1 também atrasa, mas não recupera. É quase como se esses poucos segundos não tivessem acontecido. Ele também mostra um aumento nos processos de espera e um downtick em interrupções e interrupções de contexto:
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 132 3111220 305540 588012 0 0 0 0 1035 151 1 1 99 0 0
0 0 132 3111096 305540 588012 0 0 0 0 1019 125 0 0 99 0 0
0 0 132 3111220 305540 588012 0 0 0 44 1034 154 0 1 99 0 0
1 0 132 3111096 305540 588012 0 0 0 0 1016 131 0 0 99 0 0
6 0 132 3111096 305540 588012 0 0 0 0 417 82 0 0 100 0 0
0 0 132 3111220 305540 588012 0 0 0 0 1041 155 0 1 99 0 0
0 0 132 3111096 305540 588012 0 0 0 0 1019 123 1 1 99 0 0
0 0 132 3111220 305540 588012 0 0 0 0 1032 142 0 1 99 0 0
0 0 132 3111096 305544 588008 0 0 0 44 1019 134 0 0 99 0 0
A reinicialização faz o problema desaparecer por um tempo. Este tempo mais recente demorou seis dias para voltar. Não tenho certeza se isso é consistente ou não.
Inicialmente, suspeitei que o problema poderia estar relacionado ao módulo do driver de vídeo da nVidia, mas desliguei o X Windows e removi o módulo, sem alterar os sintomas.
Não há nada no dmesg ou / var / log / messages que pareça remotamente relevante ou que de alguma forma coincida com os soluços. Não parece ser um problema com um disco rígido, como eu esperaria que o iowait fosse proeminente durante o período de falta de resposta se fosse esse o caso, mas não é. É improvável que seja um problema de hardware, já que os soluços são bem regulares. Não consegui detê-los em milissegundos, mas é bem consistente em 30/4/30/4/30/4.
Alguma idéia?
Meu dinheiro ainda continua em uma falha no disco rígido. Eu tive coisas semelhantes ocorrem em desktops pessoais do Windows. E até uma velha máquina da Sun exibiu problemas semelhantes de congelamento. No entanto, eu não vou afirmar que eu mergulhei fundo o suficiente no problema para notar os segundos caindo de um shell adormecido. Independentemente disso, você pode querer ver se consegue obter alguma informação do seu controlador RAID ou descartar os discos rígidos.
Meu servidor também tem problemas. Eu encontrei esta ferramenta: link . Infelizmente meus soluços não estão ocorrendo regularmente.