Slow NFS, nfsstat -c: trường authrefrsh (còn gọi là newcreds?) Về chi tiết là gì?

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

Googling điều này dường như là một ngõ cụt hoàn toàn. người đàn ông nfsstat nói rất nhiều về chủ đề này. Gần nhất tôi có thể nhận được là tìm hiểu về những gì có lẽ là " newcreds " trước đây .

newcreds Số lần thông tin xác thực phải được làm mới.

Vấn đề của tôi là tôi nghĩ rằng tôi đang thấy hiệu suất NFS phụ so với OpenVPN và điều duy nhất tôi có thể thấy ngay đó là khác biệt đáng kể so với tất cả các kết quả của Google, đó là trường "gọi" của tôi bằng chính xác "authrefrsh" và do đó rất cao . Tất cả các kết quả đầu ra tìm kiếm luôn có authrefrsh là 0 hoặc một số rất thấp. Trước khi tôi có thể chuyển sang gỡ lỗi một số khía cạnh khác, tôi có thể sử dụng để tìm hiểu điều này có nghĩa là gì.

Hoạt động đã xem đang nổi lên một gói trên portage chia sẻ NFS. Emerge vượt qua một cái cây lớn trong quá trình hoạt động nhưng kinh nghiệm trước đó nói rằng hiệu suất tôi thấy là bất thường.

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

Tôi không thể tìm ra chính xác authrefrsh là gì (và chính tả này, đó có phải là btw có chủ ý không?) Và tại sao nó lại tăng như thế này trong trường hợp của tôi?

Từ bài báo Red Hat trong các bình luận, giải pháp nói

Đây là hành vi dự kiến.

Không hữu ích lắm nhưng nó cũng chỉ ra lý do nó xảy ra.

Nó tham chiếu cam kết a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 trong gói sunrpc di chuyển nơi diễn ra xác thực nfs. Tôi sẽ không sao chép / dán toàn bộ cam kết nhưng chủ yếu thay đổi các dòng này.

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

Hiểu biết hạn chế của tôi là dòng này di chuyển trong đó xảy ra cuộc gọi callfrfresh () (sớm hơn là muộn hơn). Đến lượt điều này có nghĩa là hầu hết tất cả các yêu cầu nfs sẽ khiến authrefrsh tăng lên khi xác thực luôn được sử dụng.

Tôi đang thấy điều tương tự (không sử dụng vpn) - authrefrsh == các cuộc gọi ở phía máy khách. Dường như với tôi như số lượng cuộc gọi tăng lên, sau đó chậm lại và số lượng authrefrsh sau đó bắt kịp.

Số liệu thống kê rpc của khách hàng:

calls      retrans    authrefrsh
261697     0          261697

Tôi cũng thấy iowait rất cao:

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

(từ iuler :)

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

Tôi không thể thấy bất cứ điều gì bất thường trong wireshark - Tôi đang sử dụng nfs3 và tcp.

Từ những gì tôi hiểu từ liên kết này, authrefresh = các cuộc gọi không chỉ ra vấn đề.

https://ormszilla.redhat.com/show_orms.cgi?id=785931