Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!Firewall!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.protocols.nfs Subject: Re: NFS Performance Message-ID: Date: 14 Jun 91 18:42:39 GMT References: <1991Jun12.110005.3386@fennel.cc.uwa.oz.au> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 26 In-reply-to: r_hockey@fennel.cc.uwa.oz.au's message of 12 Jun 91 03:00:04 GMT 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. Just reduce the number of nfsds to 4... The problem will go away, and you don't really lose IO performance between 8 and 4 nfsds, even if there are people who argue to the contrary. Try it. Or you could buy a Sun 4 which has many more MMU/cache contexts and runs a newer release of the OS in which the problem has been worked around a bit. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk