Eu tenho um servidor de arquivos CentOS 6.4 executando o NFS 4, atendendo a alguns sistemas de arquivos XFS. Há algumas dezenas de clientes conectados a ele. Hoje ele desacelerou para um rastreamento para os clientes - os clientes travariam ou só responderiam depois de alguns minutos ao acessar o compartilhamento NFS montado do servidor. No próprio servidor eu poderia acessar os sistemas de arquivos compartilhados sem problemas. O problema desapareceu depois de cerca de quatro horas, mas não sei porque - veja abaixo.
top mostrou vários processos migration e xfssyncd processando quantidades incomuns de cpu, pulando entre 0% e em qualquer lugar até 100% a cada poucos segundos. Nenhum outro processo estava visivelmente ativo. O uso geral de CPU relatado por top foi baixo, assim:
Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Eu não consegui encontrar nada on-line falando sobre isso em particular, além de uma entrada de suporte do RHEL que está em sua seção somente para assinantes e não consigo ver.
Eu corri service nfs restart . Então service nfs status mostrou daemons em execução, exceto nfsd dead but subsys locked . Depois de outra reinicialização, isso acabou e o nfsd estava em execução, mas os clientes ainda estavam suspensos.
Eu tentei algumas coisas que foram sugeridas para problemas relacionados ao xfssyncd:
1) mount –o remount /mnt/data nos fs exportados. Curiosamente, esse comando levou cerca de um minuto para ser executado e, durante esse tempo, os processos "selvagens" se acalmaram. Mas uma vez que o comando acabou de ser executado, os processos voltaram a ter alto uso da CPU.
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecs para alterar o intervalo de sincronização do xfssyncd. Isso não fez nenhuma diferença perceptível, o que não é muito surpreendente, já que o fs está ocupado com clientes NFS e o problema deve ser algo diferente.
Eu tive um problema com esse servidor há 3 semanas, no qual um arquivo .nfsNNN (de um arquivo removido ainda estava aberto e sendo acessado) estava sendo preenchido rapidamente com uma mensagem de erro de loop em um cliente. Matar o processo do problema corrigiu a lentidão do NFS. [No entanto, o servidor de arquivos começou a desacelerar novamente alguns dias depois sem esse problema de arquivo .nfsNNN, e eu tive que reiniciá-lo. Na época, vi alguns processos com níveis de CPU não usuais, mas não notei o que eles eram e não me lembro agora se fossem os mesmos da edição atual.]
Procurei hoje novamente por abrir arquivos .nfsNNN que talvez fossem problemas, mas não encontrei nenhum. Eu deletei alguns de alguns meses atrás, mas eles não estavam sendo modificados no momento, então imaginei que eles não eram um problema. Não notei diferença depois de excluir esses arquivos.
Cerca de uma hora depois de tentar várias coisas acima, o servidor voltou ao normal e os processos migration e xfssyncd não tiveram mais uso de cpu. Eu não sei o que mudou, mas eu gostaria de tentar superar isso, já que parece que isso pode acontecer novamente.
Obrigado por qualquer sugestão.
-M