Повільний NFS, nfsstat -c: про що детально йде поле authrefrsh (aka newcreds?)?

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

Гуглінг, здається, є цілковитою тупиком. man nfsstat говорить багато нічого про цю тему. Найближчим, що я міг отримати, було дізнатися про те, що, ймовірно, раніше було « новобранцями ».

newcreds Кількість разів, коли інформацію про автентифікацію довелося оновлювати.

Моя проблема полягає в тому, що я думаю, що я бачу продуктивність NFS subpar над OpenVPN, і єдине, що я можу відразу побачити, що суттєво відрізняється від усіх результатів nfsstat Google, - це те, що моє поле "дзвінки" дорівнює точно "authrefrsh" і тому дуже високо . Усі результати пошуку завжди мали authrefrsh як 0 або дуже низьке число. Перш ніж перейти до налагодження деяких інших аспектів, я міг би дізнатися, що це означає.

Переглянута операція - це новий пакет через NFS-передачу. Компанія emerge перетинає велике дерево під час своєї роботи, але попередній досвід говорить про те, що вистава, яку я бачу, ненормальна.

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

Я не можу точно зрозуміти, що таке authrefrsh (а це написання, це навмисне btw?), І чому він збільшується так у моєму випадку?

З статті Red Hat у коментарях рішення йдеться

Це очікувана поведінка.

Не дуже корисно, але це також вказує на причину цього.

Він посилається на фіксування a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 в пакеті sunrpc, який переміщується там, де відбувається аутентифікація nfs. Я не буду копіювати / вставляти цілу комісію, але це здебільшого змінює ці рядки.

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

Моє обмежене розуміння полягає в тому, що цей рядок рухається там, де відбувається call_refresh () (раніше, ніж пізніше). Це в свою чергу означає, що більшість всіх запитів nfs призведе до збільшення authrefrsh, оскільки аутентифікація завжди використовується.

Я бачу те саме (не використовуючи vpn) - authrefrsh == дзвонить на стороні клієнта. Мені здається, що кількість викликів збільшується, потім сповільнюється, а кількість authrefrsh потім наздоганяє.

Статистика клієнта RPC:

calls      retrans    authrefrsh
261697     0          261697

Я бачу дуже високу кількість очікувань:

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

(від іостату :)

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

Я не можу побачити нічого незвичайного в проводці - я використовую nfs3 та tcp.

З того, що я розумію за цим посиланням, authrefresh = дзвінки не вказують на проблему.

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