Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

Googling this seems to be a complete dead end. man nfsstat says a whole lot of nothing about the subject. The closest I could get was finding out about what was probably previously "newcreds".

newcreds Number of times authentication information had to be refreshed.

My problem is that I think I'm seeing subpar NFS performance over OpenVPN and the only thing I can immediately see that is significantly different than all nfsstat Google results, is that my "calls" field equals exactly "authrefrsh" and is therefore very high. All the search result outputs always had authrefrsh as 0 or a very low number. Before I can move on to debugging some other aspects, I could use finding out what this means.

Watched operation is emerging a package over NFS-shared portage. emerge does traverse a big tree during it's operation but previous experience says the performance I'm seeing is abnormal.

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

I can't figure out exactly what authrefrsh is (and this spelling, is that intentional btw?) and why is it increasing like this in my case?

share|improve this question
    
When you say slow NFS, what leads you to believe that the NFS performance should be faster? Can you quantify slow? Does time of day matter WRT performance? –  Mike Pennington May 24 '11 at 11:07
    
"Slow NFS" means that NFS traffic should have no trouble taking up whole bandwidth available, which over VPN wasn't that much (100 kB/sec). Instead iftop was showing me traffic of only single digit kB/sec over tun0. I believe I have narrowed the problem down to Portage stat'ing a couple of thousand packages in my PKGDIR during binpkg related emerge runs, which seems to be excruciatingly slow operation. From what I can tell so far, the best solution might be having regularly updated squashfs portage on the remote workstations and getting binpkgs over HTTP binhost, instead of NFS-mounted PKGDIR. –  lkraav Jun 5 '11 at 0:42
    
Any updates on this? I've noticed poorer NFS client performance with newer SLES 11 and CentOS 6 servers when compared to our older SLES 9 servers. SLES 9 clients are speedier, and also show authrefrsh=0, while the newer OS' show a ton of authrefrsh. I think there is a correlation here, but not quite sure what this all means. –  Banjer May 5 '13 at 15:55
    
What type of NFS authentication are you doing? AUTH_SYS? –  Joel Davis May 7 '13 at 15:13
    
To answer part of your question though, authrefrsh is the number of times the NFS client has called call_refresh() which is basically going out to the RPC server (portmap, rpcbind, etc) and validating its credentials with the server. We need to figure out if it's actually what's causing the latency. If you're doing AUTH_SYS then the overhead is low and wouldn't be the cause. –  Joel Davis May 7 '13 at 15:16
show 9 more comments

2 Answers

I'm seeing the same thing (not using vpn) - authrefrsh == calls on the client side. It seems to me like the number of calls increases, then slows down, and the number of authrefrsh then catches up.

Client rpc stats:

calls      retrans    authrefrsh
261697     0          261697

I see very high iowait too:

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

(from iostat:)

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

I can't see anything unusual in wireshark - I'm using nfs3 and tcp.

share|improve this answer
add comment

From what I understand from this link, authrefresh = calls isn't indicating a problem.

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

share|improve this answer
    
Welcome to Unix & Linux! Generally we like answers on the site to be able to stand on their own - Links are great, but if that link ever breaks the answer should have enough information to still be helpful. Please consider editing your answer to include more detail. See the FAQ for more info. –  slm Apr 15 '13 at 18:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.