On Thu, Jul 7, 2011 at 6:23 PM, Ray Van Dolson <[email protected]> wrote: > I'm looking for a little bit of clarification. NFSD_SERVERS, per the > man page controls: > > "the maximum number of concurrent NFS requests that the server > can handle." > > Is a request represented by a unique TCP connection (assuming in this > case NFSv3 via TCP) or does it represent a single comand (GETATTR, > SETATTR, etc) on an existing session?
It has nothing to do with sessions. The NFS service is implemented in a threaded model (as opposed to an async I/O model). What this means is that you need a number of threads such that at peak time the CPU and disk I/O utilization are as high as possible. When idle, too many threads is just a small waste of memory. When busy, too many threads means spending too much time doing context switches at worst, or simply wasting some memory at best. An async I/O model would mean that you'd need no more threads than there are CPUs. > I have a somewhat busy NFS server handling approximately 2200 or so > read/write reqeusts per second (per nfsstat -v 3 1). There are only > about 30 open NFS TCP sessions however (per netstat -n | grep 2049). > > I'm wondering if I should bump my NFSD_SERVERS from 1024 to something > higher to improve performance? I suspect that there's not more than 1024 pending requests at any given time (since most of those 2200/s requests will take well under a second to complete), in which case there's little point in increasing NFSD_SERVERS. A DTrace script that measures the number of requests queued due to unavailability of NFSD threads would be nice. You'd want to combine that with measures of CPU and I/O utilization. Nico -- _______________________________________________ nfs-discuss mailing list [email protected]
