Slow NFS, nfsstat -c: o czym jest szczegółowo pole authrefrsh (aka newcreds?)?

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

Googlowanie wydaje się kompletnym ślepym zaułkiem. man nfsstat mówi wiele na ten temat. Najbliżej udało mi się dowiedzieć o tym, co prawdopodobnie było wcześniej „ nowymi ”.

newcreds Ile razy informacje o uwierzytelnianiu musiały zostać odświeżone.

Mój problem polega na tym, że myślę , że widzę obniżoną wydajność NFS w stosunku do OpenVPN, a jedyną rzeczą, którą od razu widzę, która jest znacząco inna niż wszystkie wyniki nfsstat Google, jest to, że moje pole „połączeń” jest równe dokładnie „authrefrsh” i dlatego jest bardzo wysokie . Wszystkie wyniki wyników wyszukiwania zawsze miały authrefrsh jako 0 lub bardzo niską liczbę. Zanim przejdę do debugowania innych aspektów, mógłbym dowiedzieć się, co to znaczy.

Obserwowana operacja wyłania pakiet przez portage współdzielony przez NFS. emerge przemierza duże drzewo podczas jego działania, ale wcześniejsze doświadczenia mówią, że wydajność, którą widzę, jest nienormalna.

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

Nie mogę dokładnie ustalić, co to jest authrefrsh (i ta pisownia, czy to celowe btw?) I dlaczego w moim przypadku rośnie tak?

Z artykułu Red Hat w komentarzach wynika, że ​​rozwiązanie

Jest to oczekiwane zachowanie.

Niezbyt pomocny, ale wskazuje również powód, dla którego tak się dzieje.

Odwołuje się do zatwierdzenia a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 w pakiecie sunrpc, który przesuwa się tam, gdzie ma miejsce uwierzytelnianie NFS. Nie będę kopiować / wklejać całego zatwierdzenia, ale to głównie zmienia te linie.

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

Moje ograniczone zrozumienie jest takie, że ta linia przesuwa się tam, gdzie dzieje się call_refresh () (wcześniej niż później). To z kolei oznacza, że ​​większość wszystkich żądań NFS spowoduje wzrost authrefrsh, ponieważ zawsze używane jest uwierzytelnianie.

Widzę to samo (nie używając VPN) - wywołania authrefrsh == po stronie klienta. Wydaje mi się, że liczba połączeń wzrasta, a następnie zwalnia, a liczba authrefrsh następnie się zwiększa.

Statystyki rpc klienta:

calls      retrans    authrefrsh
261697     0          261697

Widzę też bardzo wysoki iowait:

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

(od iostat :)

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

Nie widzę nic niezwykłego w wireshark - używam nfs3 i tcp.

Z tego, co rozumiem z tego linku, wywołania authrefresh = nie wskazują na problem.

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