nfsd 4, why, and how to tune...

George Robbins grr at cbmvax.commodore.com
Mon May 27 09:20:38 AEST 1991


In article <RUSTY.91May24113908 at groan.Berkeley.EDU> rusty at groan.Berkeley.EDU (Rusty Wright) writes:
> The metric I heard at a presentation about system tuning by a guy from
> Sun at the Sun User Group meeting is that you want 2 nfsd's per
> exported filesystem (or was it per disk drive).  My guess is that's 1
> to handle the reads and 1 to handle the writes so that if you export
> filesystems readonly you could drop the number of nfsd's.  Likewise if
> any of the filesystems are accessed infrequently.

Frankly, this sounds like suicide the way the Ultrix NFS deamons like to
misbehave.  Also, it might be better advice for a dedicated server than
a timesharing system that heappens to export many of it's filesystems.

I'm really curious whether the Ultrix behavior is a result of bugs or
simply the way that all NFS servers act.  The worst case seems to be "find"
which reads "directories" rather than "files", which I believe are different
classes of operation under NFS.  It may be that "stateless" behavior that
NFS implements turns sequentially "reading" a directory into some highly
cpu intensive search and search again algorithm.
 
[ for c.p.nfs types: a client doing a "find" against an Ultrix NFS exported
  filesystem brings the server to it's knees, with the NFS deamons sharing
  ~100% of the CPU time amongst themselves...  Ouch.  This happens often
  enough to be a recognizable syndrome and prompts a witch hunt to find
  which client is up to mischief ]


-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)



More information about the Comp.unix.ultrix mailing list