Slow NFS, nfsstat -c: de quoi parle le champ authrefrsh (aka newcreds?) En détail?

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

Googler cela semble être une impasse complète. man nfsstat ne dit pas grand-chose sur le sujet. Le plus proche que j'ai pu obtenir était de découvrir ce qui était probablement auparavant des « nouveaux crédits ».

newcreds Nombre de fois où les informations d'authentification ont dû être actualisées.

Mon problème est que je pense que je vois des performances NFS inférieures à OpenVPN et la seule chose que je peux voir immédiatement qui est significativement différente de tous les résultats nfsstat de Google, c'est que mon champ "appels" est exactement "authrefrsh" et est donc très élevé . Toutes les sorties de résultats de recherche avaient toujours une valeur d'authrefrsh égale à 0 ou un nombre très faible. Avant de pouvoir passer au débogage de certains autres aspects, je pourrais découvrir ce que cela signifie.

L'opération surveillée fait émerger un package sur le portage partagé NFS. emerge traverse un grand arbre pendant son fonctionnement, mais l'expérience précédente indique que les performances que je vois sont anormales.

$ 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%

Je ne peux pas comprendre exactement ce qu'est authrefrsh (et cette orthographe, est-ce intentionnel?) Et pourquoi augmente-t-il comme ça dans mon cas?

D'après l' article de Red Hat dans les commentaires, la solution dit

Il s'agit d'un comportement attendu.

Pas très utile, mais cela indique également la raison pour laquelle cela se produit.

Il fait référence à la validation a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 dans le package sunrpc qui se déplace là où l'authentification nfs a lieu. Je ne vais pas copier / coller l'intégralité du commit mais cela change surtout ces lignes.

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

Ma compréhension limitée est que cette ligne se déplace là où le call_refresh () se produit (le plus tôt possible). Cela signifie à son tour que la plupart des requêtes nfs entraîneront une incrémentation de l'authrefrsh car l'authentification est toujours utilisée.

Je vois la même chose (n'utilisant pas vpn) - authrefrsh == appelle du côté client. Il me semble que le nombre d'appels augmente, puis ralentit, et que le nombre d'authentification se rattrape.

Statistiques RPC client:

calls      retrans    authrefrsh
261697     0          261697

Je vois aussi très haut:

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

Je ne vois rien d'inhabituel dans Wireshark - j'utilise nfs3 et tcp.

D'après ce que je comprends de ce lien, authrefresh = calls n'indique pas un problème.

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