NFS network load on 5.4-STABLE

[Mike Eubanks]

On Sat, 2005-11-26 at 21:49 -0500, Chuck Swiger wrote:
> Mike Eubanks wrote:
> > As soon as I mount my NFS file systems, the network load increases to a
> > constant 80%-90% of network bandwidth, even when the file systems are
> > not in use.  NFS stats on the client machine (nfsstat -c) produce the
> > following:
> [ ... ]
> > Fsstat and Requests are increasing very rapidly.  Both the client and
> > server are i386 5.4-STABLE machines.  Is this behaviour normal?
> 
> Sort of.  Some fancy parts of X like file-manager/exporer applications tend to 
> call fstat() a lot, but it's probably tunable, and if you enable NFS attribute 
> caching that will help a lot.

  Thank you for the reply Chuck.  It seems that it is something to do
with Gnome.  I haven't done an upgrade to 2.12 yet, but the difference
did happen when I refreshed my user configuration to remove any stale
config files.  Using the "top -mio" command I get the following:

VCSW  IVCSW   READ  WRITE  FAULT  TOTAL PERCENT COMMAND
  38     56      0      0      0      0   0.00% libgtop_server
  94     16      0      0      0      0   0.00% Xorg
   4      0      0      0      0      0   0.00% top
   0      0      0      0      0      0   0.00% mozilla-bin
 115     40      0      0      0      0   0.00% multiload-appl
  42      1      0      0      0      0   0.00% anjuta-bin
   0      0      0      0      0      0   0.00% evolution-2.2
 130      9      0      0      0      0   0.00% gnome-terminal
  15     10      0      0      0      0   0.00% clock-applet
  42      0      0      0      0      0   0.00% mixer_applet2
  10      0      0      0      0      0   0.00% metacity
   3      0      0      0      0      0   0.00% nautilus
   4      0      0      0      0      0   0.00% wnck-applet

When I unmount the NFS share, the involuntary context switches drop to
nearly 0 and the voluntary context switches drop significantly.  Other
than that, everything else stayed at 0.  I have dumped the traffic on
the network adapter in question.  With abbreviated host names, there are
miles of the following.
                                     +---- file-manager/explorer?
                                     |
client.220312819 > server.nfs: 96 fsstat [|nfs]
server.nfs > client.220312819: reply ok 168 fsstat POST: DIR 755 ids
1001/0 [|nfs]
client.220312820 > server.nfs: 96 fsstat [|nfs]
server.nfs > client.220312820: reply ok 168 fsstat POST: DIR 755 ids
1001/0 [|nfs]
client.220312821 > server.nfs: 96 fsstat [|nfs]
server.nfs > client.220312821: reply ok 168 fsstat POST: DIR 755 ids 0/0
[|nfs]
client.220312822 > server.nfs: 96 fsstat [|nfs]
server.nfs > client.220312822: reply ok 168 fsstat POST: DIR 755 ids 0/0
[|nfs]
client.220312823 > server.nfs: 96 fsstat [|nfs]
server.nfs > client.220312823: reply ok 168 fsstat POST: DIR 755 ids 0/0
[|nfs]

If this is enough evidence for the file-manager/explore, I'll just have
to accept it for now.  I can't find anything about tuning them.  As far
as attribute caching, do you mean the `-o ac*' options to mount_nfs?  I
also noticed two sysctl values, although, I left them unmodified.

vfs.nfs.access_cache_timeout: 2
vfs.nfs4.access_cache_timeout: 60

>   "ls /afs", if available, is a wonderful test of 
> whether a program/file-manager is being polite.

I better read a book on this first if you're talking about the Andrew
File System.  Any suggestions?

> 
> Anyway, "top -mio" is likely to be informative.
> 


-- 
Mike Eubanks <mse_software at charter.net>