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