NFS lento, nfsstat -c: ¿de qué se trata el campo authrefrsh (aka newcreds?) En detalle?

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

Buscar en Google esto parece ser un callejón sin salida completo. man nfsstat no dice mucho sobre el tema. Lo más cerca que pude llegar fue averiguar acerca de lo que probablemente antes eran " recién llegados ".

newcreds Número de veces que la información de autenticación tuvo que actualizarse.

Mi problema es que creo que estoy viendo un rendimiento de NFS inferior a OpenVPN y lo único que puedo ver de inmediato que es significativamente diferente de todos los resultados de Google nfsstat, es que mi campo "llamadas" es exactamente "authrefrsh" y, por lo tanto, es muy alto . Todas las salidas de resultados de búsqueda siempre tenían authrefrsh como 0 o un número muy bajo. Antes de poder continuar con la depuración de algunos otros aspectos, podría usar para descubrir lo que esto significa.

La operación observada está emergiendo en un paquete a través del portage compartido NFS. emerge atraviesa un gran árbol durante su funcionamiento, pero la experiencia previa dice que el rendimiento que estoy viendo es 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%

No puedo entender exactamente qué es authrefrsh (y esta ortografía, ¿es intencional por cierto?) Y ¿por qué está aumentando así en mi caso?

gentoo nfs openvpn

— lkraav
fuente

Cuando dices NFS lento, ¿qué te lleva a creer que el rendimiento de NFS debería ser más rápido? ¿Puedes cuantificar lento? ¿Importa la hora del día el rendimiento de WRT?

— Mike Pennington

"NFS lento" significa que el tráfico NFS no debería tener problemas para ocupar todo el ancho de banda disponible, que a través de VPN no era tanto (100 kB / seg). En cambio, iftop me mostraba tráfico de solo un dígito kB / seg sobre tun0. Creo que he reducido el problema a Portage con un par de miles de paquetes en mi PKGDIR durante las ejecuciones de emergencia relacionadas con binpkg, lo que parece ser una operación extremadamente lenta. Por lo que puedo decir hasta ahora, la mejor solución podría ser actualizar regularmente el porte de squashfs en las estaciones de trabajo remotas y obtener binpkgs a través de HTTP binhost, en lugar de PKGDIR montado en NFS.

— lkraav

¿Alguna actualización sobre esto? He notado un peor rendimiento del cliente NFS con los servidores SLES 11 y CentOS 6 más nuevos en comparación con nuestros servidores SLES 9 más antiguos. Los clientes de SLES 9 son más rápidos y también se muestran authrefrsh=0, mientras que los SO más nuevos muestran una tonelada de authrefrsh. Creo que hay una correlación aquí, pero no estoy muy seguro de qué significa todo esto.

— Banjer

¿Qué tipo de autenticación NFS estás haciendo? AUTH_SYS?

— Bratchley

Sin embargo, para responder parte de su pregunta, authrefrsh es la cantidad de veces que el cliente NFS ha llamado call_refresh()que básicamente va al servidor RPC (portmap, rpcbind, etc.) y valida sus credenciales con el servidor. Necesitamos averiguar si en realidad es lo que está causando la latencia. Si lo está haciendo AUTH_SYS, la sobrecarga es baja y no sería la causa.

— Bratchley

Respuestas:

Del artículo de Red Hat en los comentarios, la solución dice

Este es el comportamiento esperado.

No es muy útil, pero también señala la razón por la que sucede.

Hace referencia a commit a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 en el paquete sunrpc que se mueve donde tiene lugar la autenticación nfs. No copiaré / pegaré todo el commit, pero en su mayoría cambia estas líneas.

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

Mi comprensión limitada es que esta línea se mueve donde ocurre call_refresh () (más temprano que tarde). Esto a su vez significa que la mayoría de las solicitudes nfs harán que aumente authrefrsh ya que la autenticación siempre se usa.

— Rothgar
fuente

Estoy viendo lo mismo (sin usar vpn): authrefrsh == llamadas en el lado del cliente. Me parece que la cantidad de llamadas aumenta, luego se ralentiza y la cantidad de authrefrsh se pone al día.

Estadísticas de rpc del cliente:

calls      retrans    authrefrsh
261697     0          261697

También veo muy alto iowait:

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

(de iostat :)

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

No puedo ver nada inusual en wireshark: estoy usando nfs3 y tcp.

— Andy
fuente

Por lo que entiendo de este enlace, authrefresh = llamadas no indica un problema.

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

— Gene O
fuente

¡Bienvenido a Unix y Linux! En general, nos gusta que las respuestas en el sitio sean independientes: los enlaces son geniales, pero si ese enlace alguna vez se rompe, la respuesta debería tener suficiente información para ser útil. Considere editar su respuesta para incluir más detalles. Consulte las preguntas frecuentes para obtener más información.

— slm

lo que quieren decir es que no están seguros de que sea la causa del problema o que simplemente aumenten debido a él. "dispararse" definitivamente indica que las cosas no están bien. Del mismo modo, esto se ve principalmente en paralelo con los problemas de rendimiento feo.

— Florian Heigl