NFS lento, nfsstat -c: sobre o que é o campo authrefrsh (também conhecido como newcreds?) Em detalhes?

(net-fs / nfs-utils-1.2.3-r1, 2.6.38.5-zen + Gentoo)

Pesquisando isso, parece ser um beco sem saída. man nfsstat não diz muito sobre o assunto. O mais próximo que pude chegar foi descobrir o que provavelmente era " novatos ".

newcreds Número de vezes que as informações de autenticação tiveram que ser atualizadas.

Meu problema é que acho que estou vendo desempenho abaixo do NFS em relação ao OpenVPN e a única coisa que vejo imediatamente que é significativamente diferente de todos os resultados do nfsstat do Google é que meu campo "calls" é exatamente igual a "authrefrsh" e, portanto, é muito alto . Todas as saídas dos resultados da pesquisa sempre tiveram authrefrsh como 0 ou um número muito baixo. Antes que eu possa passar a depurar alguns outros aspectos, eu poderia descobrir o que isso significa.

A operação assistida está emergindo um pacote sobre o portage compartilhado pelo NFS. O emerge atravessa uma grande árvore durante sua operação, mas a experiência anterior diz que o desempenho que estou vendo é anormal.

$ watch -n 1 nfsstat -c

Every 1,0s: nfsstat -c                                Sat May 21 23:04:55 2011

Client rpc stats:
calls      retrans    authrefrsh
308565     2211       308565

Client nfs v3:
null         getattr      setattr      lookup       access       readlink
0         0% 172372   55% 17        0% 30485     9% 36057    11% 26831     8%
read         write        create       mkdir        symlink      mknod
25879     8% 107       0% 21        0% 0         0% 0         0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus
16        0% 0         0% 11        0% 0         0% 0         0% 16668     5%
fsstat       fsinfo       pathconf     commit
3         0% 50        0% 25        0% 2         0%

Não consigo descobrir exatamente o que é authrefrsh (e essa ortografia, isso é intencional?) E por que está aumentando assim no meu caso?

gentoo nfs openvpn

— lkraav
fonte

Quando você diz NFS lento, o que o leva a acreditar que o desempenho do NFS deve ser mais rápido? Você pode quantificar devagar? A hora do dia importa o desempenho do WRT?

— Mike Pennington

"NFS lento" significa que o tráfego NFS não deve ter problemas em ocupar toda a largura de banda disponível, o que pela VPN não era muito (100 kB / s). Em vez disso, o iftop estava me mostrando tráfego de apenas um dígito kB / s no tun0. Acredito que reduzi o problema até o Portage declarando alguns milhares de pacotes no meu PKGDIR durante as execuções emergentes relacionadas ao binpkg, o que parece ser uma operação extremamente lenta. Pelo que sei até agora, a melhor solução pode ser ter o portage squashfs atualizado regularmente nas estações de trabalho remotas e obter binpkgs sobre HTTP binhost, em vez de PKGDIR montado em NFS.

— lkraav

Alguma atualização sobre isso? Percebi um desempenho inferior do cliente NFS nos servidores SLES 11 e CentOS 6 mais recentes, quando comparado aos servidores SLES 9 mais antigos. Os clientes do SLES 9 são mais rápidos e também mostram authrefrsh=0, enquanto os sistemas operacionais mais recentes mostram uma tonelada de authrefrsh. Eu acho que há uma correlação aqui, mas não tenho certeza do que isso tudo significa.

— Banjer

Que tipo de autenticação NFS você está fazendo? AUTH_SYS?

— Bratchley

Para responder parte de sua pergunta, authrefrsh é o número de vezes que o cliente NFS ligou, call_refresh()basicamente indo para o servidor RPC (portmap, rpcbind, etc.) e validando suas credenciais com o servidor. Precisamos descobrir se é realmente o que está causando a latência. Se você estiver fazendo AUTH_SYS, a sobrecarga é baixa e não seria a causa.

— Bratchley

Respostas:

No artigo da Red Hat nos comentários, a solução diz

Este é o comportamento esperado.

Não é muito útil, mas também aponta a razão pela qual isso acontece.

Ele faz referência a commit a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 no pacote sunrpc que se move para onde a autenticação nfs ocorre. Não vou copiar / colar todo o commit, mas ele altera essas linhas principalmente.

-struct rpc_cred *cred = task->tk_msg.rpc_cred;
+struct rpc_cred *cred = task->tk_rqstp->rq_cred;

Meu entendimento limitado é que essa linha se move onde o call_refresh () acontece (mais cedo ou mais tarde). Por sua vez, isso significa que a maioria das solicitações nfs fará com que o authrefrsh seja incrementado, pois a autenticação sempre é usada.

— Rothgar
fonte

Estou vendo a mesma coisa (não usando vpn) - authrefrsh == chama no lado do cliente. Parece-me que o número de chamadas aumenta, diminui a velocidade e o número de authrefrsh alcança.

Estatísticas de rpc do cliente:

calls      retrans    authrefrsh
261697     0          261697

Também vejo iowait muito alto:

dd if=/dev/zero of=/mnt/omoikane/testfile bs=16k count=2048

(do iostat :)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          4.04    0.00    4.04   91.92    0.00    0.00

Não vejo nada incomum no wireshark - estou usando o nfs3 e o tcp.

— Andy
fonte

Pelo que entendi neste link, authrefresh = calls não está indicando um problema.

https://bugzilla.redhat.com/show_bug.cgi?id=785931

— Gene O
fonte

Bem-vindo ao Unix e Linux! Geralmente, gostamos de respostas no site para poder se manter por conta própria - os links são ótimos, mas se esse link quebrar, a resposta deve ter informações suficientes para continuar sendo útil. Considere editar sua resposta para incluir mais detalhes. Veja o FAQ para mais informações.

— Slm

o que eles querem dizer é que não têm certeza de que é a causa do problema ou apenas aumentam devido a ele. "disparar" definitivamente indica que as coisas não estão bem. Da mesma forma, isso é visto principalmente em paralelo com problemas de desempenho feios.

— Florian Heigl