Date: Fri, 01 Dec 2006 21:46:04 -0800 From: Frank Mayhar <frank@exit.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Robert Watson <rwatson@freebsd.org>, Ivan Voras <ivoras@fer.hr>, freebsd-arch@freebsd.org Subject: Re: What is the PREEMPTION option good for? Message-ID: <1165038364.8249.8.camel@jill.exit.com> In-Reply-To: <200612020454.kB24sIpq071255@apollo.backplane.com> References: <20061119041421.I16763@delplex.bde.org> <ejnvfo$tv2$1@sea.gmane.org> <ek4gc8$492$1@sea.gmane.org> <20061126174041.V83346@fledge.watson.org> <ekckpt$4h6$1@sea.gmane.org> <20061128142218.P44465@fledge.watson.org> <45701A49.5020809@fer.hr> <20061202094431.O16375@delplex.bde.org> <200612020454.kB24sIpq071255@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2006-12-01 at 20:54 -0800, Matthew Dillon wrote: > The single biggest NFS client performance issue I have encountered > in an environment where most of the data can be cached from earlier > runs is with negative name lookups. Due the large number of -I > options used in builds, the include search path is fairly long and > this usually results in a large number of negative lookups, all of > which introduce synchronous dead times while the stat() or open() > waits for the over-the-wire transaction to complete. > > The #1 solution is to cache negative namecache hits for NFS clients. > You don't have to cache them for long... just 3 seconds is usually > enough to remove most of the dead time. Also make sure your access > cache timeout is something reasonable. Back in my early Locus days, 1994 or 95, we ran into the same phenomenon while benchmarking our distributed file system. The SVR4.2 name cache didn't cache negative lookups and that killed us on certain performance benchmarks, even locally (since we nearly doubled the code path) much less when the file system actually lived on a remote node. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1165038364.8249.8.camel>