grr@cbmvax.commodore.com (George Robbins) (05/27/91)
In article <RUSTY.91May24113908@groan.Berkeley.EDU> 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)
mark@loki.une.oz.au (Mark Garrett) (05/27/91)
grr@cbmvax.commodore.com (George Robbins): > In article <RUSTY.91May24113908@groan.Berkeley.EDU> rusty@groan.Berkeley.EDU (Rusty Wright) writes: > 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 ] I've only got ultrix to play with, and it was only last weekend that I gave NFS its first run ,exporting src from a VAX3500 to a DecSystem5400 , to find that the 3500 got a real kick in the response time with very little NFS effort. I was not impressed, believing this to be normal behavior for NFS I'm glad to hear its Ultrix (sort of). Has Ultrix 4.2 fixed this, would BSD source for NFS have the same problems ? -- Mark Garrett Internet: mark@loki.une.edu.au Phone: +61 (066) 20 3859 University of NewEngland, Northern Rivers, Lismore NSW Australia.
jim@cs.strath.ac.uk (Jim Reid) (05/28/91)
In article <21936@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes:
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 ]
Any recursive directory traverse via NFS can be painful (du is just as
bad as find). This is because the client makes LOTS of NFS requests -
several read directory entries to get the file names and the file
handles followed by a get file atributes request for each file. If the
client is faster at sending these out than the server is at replying,
this is bad news. The server will be bombarded with NFS requests which
it can't service quickly enough. The requests timeout, so the client
sends them all over again, saturating the server once more and closing
the loop. Another nasty is that the client and server file attribute
caches will get flushed and filled with entries from the traverse.
This can mean that heavily used cache entries have been removed to
make way for those at the tail of the directory traverse.
Increasing the number of nfsds on the server may help in this
situation, but I doubt it. [It's already working the disk as hard as
it can so another nsfd process to enqueue requests to the server's
disk driver isn't going to help much.] A better solution will be to
experiment with increased values for the timeout and restransmission
NFS mount parameters ON THE CLIENTS. This will make them behave less
agressively when the server is having a hard time.
Jimbrent@terra.Eng.Sun.COM (Brent Callaghan) (05/29/91)
In article <JIM.91May28110939@baird.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes: > Any recursive directory traverse via NFS can be painful (du is just as > bad as find). This is because the client makes LOTS of NFS requests - > several read directory entries to get the file names and the file > handles followed by a get file atributes request for each file. If the > client is faster at sending these out than the server is at replying, > this is bad news. The server will be bombarded with NFS requests which > it can't service quickly enough. The requests timeout, so the client > sends them all over again, saturating the server once more and closing > the loop. No, this isn't right. The biod's on an NFS client can generate multiple concurrent requests - but only for in I/O operations: read and write. A process doing a find generates lots of READDIR's and LOOKUP's. These are executed in the context of the process generating them. For each request, the process blocks until it gets a reply from the server. If we're assuming that there's just one "find" process running on the client, then there's no way that the client can "bombard" the server with requests - it's all synchronous. Whether you do it over NFS or locally, find is a very disk intensive activity. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems Email: brent@Eng.Sun.COM phone: (415) 336 1051