Michael Conlen m at
Mon Jan 24 08:27:00 PST 2005

On Jan 23, 2005, at 4:08 PM, Robert Watson wrote:

> On Thu, 20 Jan 2005, Eric Anderson wrote:
>> I can tell you this - you must increase the number of nfsd threads to 
>> a
>> high number, if you plan on really hammering the machine with nfs and
>> lots of clients.  I recompiled the nfsd binary with it tweaked to 
>> allow
>> 256 threads, and that still isn't quite enough.  You need something on
>> the order of: 1 per active machine using nfs * 1.10.  The hard part is
>> finding out how many active machines you have.  I usually start with
>> about 20% of my total machines mounted to the server, and then watch 
>> the
>> nfsd threads cpu time. If the lowest thread is using more than about
>> 3-4% of the time of the 10-15th top nfsd process, then you need to 
>> bump
>> up the number.  That may be confusing..
> Hmm.  So it sounds like it would make sense for us to do that in the 
> src
> tree.  Is it sufficient to simply redefine MAXNFSDCNT from 20 to 256, 
> or
> do other things also need tweaking?


I had submitted some patches about six months ago to remove the 
constant but my need for paid work caught up with me and I didn't have 
time to follow up with the commiter.

The problem is that some functions (interrupt handlers for example) 
need to know the length of the array when they get called. My solution 
was to allocate the array of nfsd processes then call the and use 
varargs pass the value of -d and the location of the array to them.

Doesn't really make sense to me to have a statically compiled value at 
all. Since I'm dealing with NFS performance issues again I can dig this 
stuff up and resubmit it if your interested.

More information about the freebsd-performance mailing list