Latência em um pequeno sistema cliente / servidor Linux NFS4

Question

Somos um departamento de ciência da computação em uma pequena universidade, executando um servidor RHEL 7 usando clientes NFS4 e Fedora 24 (~ 40 máquinas clientes, ~ 150 usuários - raramente concorrentes). Estamos com problemas de latência e estamos tendo problemas para solucionar problemas / tentando descobrir qual é o problema. Exemplos dos sintomas:

• O Emacs leva cerca de 2 minutos para iniciar / ser utilizável. A GUI aparece rapidamente, mas o aplicativo trava se você tentar abrir um arquivo na inicialização. Se você tentar abrir emacs e então tentar abrir um arquivo, o aplicativo trava por dois minutos. Após cerca de dois minutos, você pode criar arquivos, ler arquivos, etc., sem problemas. EDIT: executar emacs em um arquivo local (por exemplo, /tmp/test.out) não tem o problema de latência. Além disso, a abertura de arquivos em rede usando idle3 ou gedit não tem problemas.
• Fazer check-out de um projeto usando svn + ssh na linha de comando é muito lento em uma das máquinas cliente / desktop do Linux - na ordem de 3 minutos. Se você fizer o checkout do projeto, usando svn + ssh de outra máquina, o checkout leva 3 segundos .
• Você não pode configurar o Idle. Quando você clica no menu de configuração, o aplicativo trava. ATUALIZADO: Este parece ser um bug no idle3 que não foi corrigido no Fedora 24, mas nós conseguimos aplicar a correção.
• Quando você clica em "abrir / navegar" em um aplicativo (por exemplo, emacs, Eclipse) ou abre o gerenciador de arquivos, o aplicativo fica travado por algum tempo enquanto recupera arquivos. Usando ls e cd da linha de comando é rápido.

Após os longos atrasos, você pode ler / editar / criar arquivos sem problemas.

A única semelhança que encontrei com esses aplicativos é que eles estão usando arquivos de configuração ocultos ( .emacs.d , .idle , .eclipse , ...). Não consigo encontrar nenhuma documentação de que arquivos ocultos sejam tratados de maneira diferente.

Qualquer conselho é apreciado!

    

Answer 1

Como resolvo isso:

1. se ~ / .emacs.d / for fornecido por uma montagem NFS e
2. o arquivo de destino é uma montagem NFS fornecida por um segundo servidor NFS e
3. copiar todo o local para o cliente remove o atraso,

Em seguida, movo um deles por vez de volta para o NFS e tento recriar o problema.

Ao reler sua postagem original, percebo que você supõe que você tenha dois ou mais servidores NFS, porque foi isso que eu vi em empregadores anteriores. Um servidor NFS forneceu diretórios base e um segundo binários fornecidos. Descobrimos a execução dos binários localmente no desempenho aprimorado do cliente. :-)

Se você tiver um servidor NFS, poderá configurar um segundo para solucionar problemas? Talvez o único servidor NFS esteja sobrecarregado em determinados momentos; trabalhar com um segundo servidor NFS pode ajudar a isolar este caso.

Se o problema aparecer em apenas um ou dois clientes, tentarei descobrir o que torna esses clientes únicos. Se o problema aparecer em todos os clientes, eu olharia para o servidor NFS.

Examinar os logs no servidor RHEL7 NFS ajudará em qualquer caso.

Uma pesquisa no Google por "NFS Troubleshooting" forneceu muitas páginas úteis, incluindo tldp . Há também a configuração do servidor nfs da Red Hat. Você provavelmente já olhou para os dois já.

Você disse que o servidor NFS é o Red Hat EL 7. Se eu tivesse um contrato de suporte com minha cópia do RHEL, eu abriria um ticket com a Red Hat e pediria que eles ajudassem a solucionar problemas também.

Espero que isso ajude. Boa sorte.

Answer 2

Quais opções de montagem você usa para o seu nfs? Remover opções como lookupcache=none (e permitir o padrão) permitirá que os clientes armazenem em cache muito mais agressivamente, notamos que isso pode confundir os usuários quando um arquivo em seu diretório inicial é adicionado e leva uma hora antes de ser visível no máquina remota, mas para binários acabou por ser bom.

Também definimos actimeo=60 e noactime na montagem de nossos aplicativos.

Pastas iniciais: rw,noatime,nfsvers=4,minorversion=1,soft,tcp,sec=sys,lookupcache=none,sloppy

aplicativos / binários: rw,noatime,nfsvers=4,minorversion=1,soft,tcp,sec=sys,actimeo=60,sloppy

veja também a seção DATA E METADATA DE COERÊNCIA na página man link