Eu tenho um servidor de arquivos CentOS 6.4 rodando NFS 4, servindo alguns sistemas de arquivos XFS. Existem algumas dezenas de clientes conectados a ele. Hoje ele ficou lento para os clientes - os clientes travavam ou respondiam apenas após alguns minutos ao acessar o compartilhamento NFS montado do servidor. No próprio servidor consegui acessar os sistemas de arquivos compartilhados sem problemas. O problema desapareceu depois de cerca de quatro horas, mas não sei por quê - veja abaixo.
topmostrou vários migrationprocessos e xfssyncdprocessos consumindo quantidades incomuns de CPU, saltando entre 0% e até 100% a cada poucos segundos. Nenhum outro processo estava visivelmente ativo. O uso geral da 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
Não consegui encontrar nada online falando sobre isso em particular, exceto possivelmente uma entrada de suporte RHEL que está na seção somente para assinantes e não consigo ver.
Eu corri service nfs restart. Em seguida, service nfs statusmostrou daemons em execução, exceto nfsd dead but subsys locked. Após outra reinicialização, isso desapareceu e o nfsd estava em execução, mas os clientes ainda estavam travados.
Tentei algumas coisas sugeridas para problemas relacionados ao xfssyncd:
1) mount –o remount /mnt/datano fs exportado. Curiosamente, esse comando demorou cerca de um minuto para ser executado e, durante esse tempo, os processos “selvagens” se acalmaram. Mas assim que a execução do comando terminou, os processos voltaram ao alto uso da CPU.
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecspara alterar o intervalo de sincronização para 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 outro.
Tive um problema com este servidor há 3 semanas, em que um arquivo .nfsNNN (de um arquivo removido ainda está aberto e sendo acessado) estava enchendo rapidamente com uma mensagem de erro em loop em um cliente. Eliminar o processo problemático corrigiu a lentidão do NFS. [No entanto, o servidor de arquivos começou a ficar lento novamente alguns dias depois, sem esse problema de arquivo .nfsNNN, e eventualmente tive que reiniciá-lo. Na época, vi alguns processos com níveis de CPU incomuns, mas não observei o que eram e não consigo lembrar agora se eram iguais ao problema atual.]
Procurei hoje novamente por arquivos .nfsNNN abertos que talvez fossem problemas, mas não encontrei nenhum. Eu excluí alguns de alguns meses atrás, mas eles não estavam sendo modificados no momento, então percebi que não eram um problema. Não notei nenhuma diferença depois de excluir esses arquivos.
Cerca de uma hora depois de tentar as várias coisas acima, o servidor voltou ao normal e os migrationprocessos xfssyncdnão apresentavam mais alto uso da CPU. Não sei o que mudou, mas gostaria de tentar descobrir isso, pois parece que pode acontecer novamente.
Obrigado por qualquer sugestão.
-M
Responder1
Eu tenho um RHEL 6.10 com problemas semelhantes. A única coisa que parece ajudar é eliminar processos SFTP de usuário de longa execução no cliente NFS. Esses eram processos mantidos abertos por clientes SFTP baseados em GUI (por exemplo, WinSCP, Nimble Commander) por muitas horas (> 10 horas).
O monitoramento mostra alguma atividade do cliente NFSv3 coincidente com o problema, mas a atividade é, na verdade, menor do que alguma outra atividade típica em outros clientes (há > 100 clientes) que não causam o problema.
Na verdade, também não há muita E/S feita.
ATUALIZAÇÃO 10/12/2019: A causa raiz parece ter sido as cotas XFS no servidor NFS. Os diretórios iniciais dos usuários têm cotas impostas, com um limite flexível 2 GB menor que o limite rígido. Alguns usuários tentaram instalar um Anaconda Python completo, que excedeu o limite flexível. O instalador do Anaconda não parecia ter uma maneira de interceptar os avisos e continuou baixando arquivos além do limite flexível. Isso gerou uma taxa enorme de avisos de cota, paralisando completamente o sistema e deixando-o sem resposta.
Digo “parece” porque a evidência é circunstancial. Quando os usuários tentaram instalar em um diretório sem cota, tudo correu bem.