Xref: utzoo comp.unix.ultrix:7387 comp.protocols.nfs:2368 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!news.cs.indiana.edu!rutgers!cbmvax!grr From: grr@cbmvax.commodore.com (George Robbins) Newsgroups: comp.unix.ultrix,comp.protocols.nfs Subject: Re: nfsd 4, why, and how to tune... Message-ID: <21936@cbmvax.commodore.com> Date: 26 May 91 23:20:38 GMT References: <119@janis.UUCP> Reply-To: grr@cbmvax.commodore.com (George Robbins) Organization: Commodore, West Chester, PA Lines: 30 In article rusty@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@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)