Date: Wed, 20 Jul 2011 16:20:09 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Zack Kirsch <zack.kirsch@isilon.com> Cc: freebsd-fs@freebsd.org Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel Message-ID: <1443258176.814644.1311193209047.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1131900815.812133.1311191015011.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
It's me again: > Zack Kirsch wrote: [good stuff snipped for brevity] > > > We've done a few things to combat this problem: > > 1) We increased the floodlevel to 65536. > > 2) We made the floodlevel configurable via sysctl. > I've thought that it would be nice to define this as a fraction of > what kern.ipc.nmbclusters is set to, but I haven't looked to see how > often an mbuf cluster ends up being a part of the cached reply. > > The 16K was just a very conservative # chosen when the server I did > load tests against had 512Mbytes of RAM. > > I think tying it to kern.ipc.nmbclusters (or directly to the machine's > RAM size or both??) would be nice. Having yet another tunable few > understand > (ie. making it a sysctl) seems a less desirable fallback plan? > I just did a quick test and it seems that the replies cached for these open_owners (and lock_owners too, I think) are usually just one mbuf, so cranking the flood level way up shouldn't be too bad. Can anyone suggest what would be an appropriate upper limit, given that each cached entry will use one small malloc'd data structure plus one mbuf (without a cluster)? rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1443258176.814644.1311193209047.JavaMail.root>