Slow NFS, nfsstat -c: Worum geht es im Feld authrefrsh (auch bekannt als newcreds?) Im Detail?

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

Googeln scheint eine Sackgasse zu sein. man nfsstat sagt viel nichts über das thema . Das nächste, was ich bekommen konnte, war herauszufinden, was wahrscheinlich vorher " Newcreds " waren.

newcreds Häufigkeit, mit der Authentifizierungsinformationen aktualisiert werden mussten.

Mein Problem ist, dass ich denke, dass ich über OpenVPN eine unterdurchschnittliche NFS-Leistung sehe. Das einzige, was ich sofort sehen kann, das sich erheblich von allen Google-Ergebnissen von nfsstat unterscheidet, ist, dass mein Feld "Anrufe" genau "authrefrsh" entspricht und daher sehr hoch ist . Alle Suchergebnisausgaben hatten immer authrefrsh als 0 oder eine sehr niedrige Zahl. Bevor ich mit dem Debuggen einiger anderer Aspekte fortfahren kann, könnte ich herausfinden, was dies bedeutet.

Watched Operation entwickelt ein Paket über NFS-Shared Portage. Emerge durchquert einen großen Baum während des Betriebs, aber frühere Erfahrungen zeigen, dass die Leistung, die ich sehe, abnormal ist.

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

Ich kann nicht genau herausfinden, was authrefrsh ist (und diese Schreibweise ist das übrigens beabsichtigt?) Und warum nimmt es in meinem Fall so zu?

gentoo nfs openvpn

— lkraav
quelle

Wenn Sie langsames NFS sagen, was lässt Sie glauben, dass die NFS-Leistung schneller sein sollte? Können Sie langsam quantifizieren? Ist die Tageszeit wichtig für die WRT-Leistung?

— Mike Pennington

"Langsames NFS" bedeutet, dass der NFS-Verkehr keine Probleme haben sollte, die gesamte verfügbare Bandbreite zu nutzen, was über VPN nicht so viel war (100 kB / s). Stattdessen zeigte mir iftop nur einstelligen kB / s Verkehr über tun0. Ich glaube, ich habe das Problem auf Portage eingegrenzt, indem ich ein paar tausend Pakete in meinem PKGDIR während binpkg-bezogener Emerge-Läufe angegeben habe, was eine äußerst langsame Operation zu sein scheint. Nach dem, was ich bisher sagen kann, besteht die beste Lösung darin, die Squashfs-Portage auf den Remote-Workstations regelmäßig zu aktualisieren und binpkgs über HTTP binhost anstelle von NFS-gemountetem PKGDIR abzurufen.

— lkraav

Irgendwelche Updates dazu? Ich habe eine schlechtere NFS-Client-Leistung mit neueren SLES 11- und CentOS 6-Servern im Vergleich zu unseren älteren SLES 9-Servern festgestellt. SLES 9-Clients sind schneller und zeigen auch authrefrsh=0, während die neueren Betriebssysteme eine Menge zeigen authrefrsh. Ich denke, hier besteht eine Korrelation, aber ich bin mir nicht ganz sicher, was dies alles bedeutet.

— Banjer

Welche Art von NFS-Authentifizierung führen Sie durch? AUTH_SYS?

— Bratchley

Um einen Teil Ihrer Frage zu beantworten, gibt authrefrsh an, wie oft der NFS-Client aufgerufen hat, call_refresh()was im Grunde an den RPC-Server (Portmap, rpcbind usw.) geht und dessen Anmeldeinformationen beim Server überprüft. Wir müssen herausfinden, ob es tatsächlich die Ursache für die Latenz ist. Wenn Sie dies tun, AUTH_SYSist der Overhead gering und würde nicht die Ursache sein.

— Bratchley

Antworten:

Aus dem Red Hat-Artikel in den Kommentaren geht die Lösung hervor

Dies ist erwartetes Verhalten.

Nicht sehr hilfreich, zeigt aber auch den Grund dafür auf.

Es verweist auf das Commit a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 im sunrpc-Paket, das sich dorthin bewegt, wo die NFS-Authentifizierung stattfindet. Ich werde nicht das gesamte Commit kopieren / einfügen, aber es ändert meistens diese Zeilen.

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

Mein begrenztes Verständnis ist, dass sich diese Zeile dorthin bewegt, wo call_refresh () stattfindet (eher früher als später). Dies bedeutet wiederum, dass die meisten nfs-Anforderungen dazu führen, dass authrefrsh erhöht wird, da immer die Authentifizierung verwendet wird.

— Rothgar
quelle

Ich sehe dasselbe (ohne VPN) - authrefrsh == ruft auf der Clientseite auf. Mir scheint, die Anzahl der Anrufe nimmt zu, verlangsamt sich dann und die Anzahl der Authrefrsh holt dann auf.

Client-RPC-Statistiken:

calls      retrans    authrefrsh
261697     0          261697

Ich sehe auch sehr hohe iowait:

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

(von iostat :)

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

Ich kann in wireshark nichts Ungewöhnliches sehen - ich benutze nfs3 und tcp.

— Andy
quelle

Nach dem, was ich unter diesem Link verstehe, weisen authrefresh = Anrufe nicht auf ein Problem hin.

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

— Gene O.
quelle

Willkommen bei Unix & Linux! Im Allgemeinen möchten wir, dass Antworten auf der Website für sich alleine stehen - Links sind großartig, aber wenn dieser Link jemals unterbrochen wird, sollte die Antwort genügend Informationen enthalten, um dennoch hilfreich zu sein. Bitte bearbeiten Sie Ihre Antwort, um weitere Details zu erhalten. Weitere Informationen finden Sie in den FAQ .

— slm

Was sie meinen ist, dass sie nicht sicher sind, ob es die Ursache des Problems ist oder nur aufgrund dessen steigt. "explodieren" bedeutet definitiv, dass die Dinge nicht in Ordnung sind. In ähnlicher Weise wird dies meistens parallel zu hässlichen Perf-Problemen gesehen.

— Florian Heigl