Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!strath-cs!baird!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.protocols.nfs Subject: Re: NFS Performance Message-ID: Date: 26 Jun 91 12:29:55 GMT References: <1991Jun12.110005.3386@fennel.cc.uwa.oz.au> Sender: jim@cs.strath.ac.uk Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 32 In-reply-to: pcg@aber.ac.uk's message of 14 Jun 91 18:42:39 GMT In article pcg@aber.ac.uk (Piercarlo Grandi) writes: On 12 Jun 91 03:00:04 GMT, r_hockey@fennel.cc.uwa.oz.au said: hockey> Has anyone seen this happen, We have a PC-NFS network with about hockey> 50 PCs served by a SUN 3/160 when a user (using a 386-25) hockey> indexes a large file with dbase III+ with both the dbase and hockey> index file on the same mounted drive the system comes to hockey> standstill. When we check the system we find all 8 nfsd's have hockey> completely taken over the whole system. It's a well known phenomenon with early releases of SunOS 4. 8 nfsds thrash the MMU/cache of a sun 3. This cache has exactly 8 slots; if only the 8 nfsds are active, everything is fine; as soon as another process starts to run, you have 9 processes scheduled round robin, and the MMU/cache is managed LRU. Every context switch brings a cache reload, which takes about 1ms on the machine you mention... and so on. This was a problem in the early days of SunOS version 3 (and before). Since SunOS3.2, the kernel has had a routine called wakeup_one() which was used to wake up exactly one idle nsfd process instead of them all. This effectively eliminated the chache thrashing phenomonon: an nfsd process would only get woken up if it had something to do. If all the MMU contexts are in use and there are more runnable processes, the cache thrashing will be negligible compared to other system overheads - waiting for some locked kernel resource to be freed to a disk I/O to complete for example. Jim