Date: Fri, 14 Oct 2005 12:39:11 -0500 From: Eric Anderson <anderson@centtech.com> To: Jim Rees <rees@umich.edu> Cc: fs@freebsd.org, rick@snowhite.cis.uoguelph.ca Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients Message-ID: <434FED3F.5060907@centtech.com> In-Reply-To: <20051014172348.46B291BBE6@citi.umich.edu> References: <20051014172348.46B291BBE6@citi.umich.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Jim Rees wrote: > Tcp always throws away retransmissions. Doesn't matter whether the data is > still in the receive socket queue or not. The nfs server will never see > replayed requests as a result of tcp retransmission. > > The problem is "how do you make sure the nfsd threads don't start a > request if the disk I/O subsystem is backlogged". > > Isn't this simply a matter of choosing the right number of nfsd threads? I don't think so - you could easily jam up 4 threads with a large number of machines, if traffic is right. Having a larger number of threads allows more clients in that case. If you have too many threads, then when the disks are busy, your load goes high (because of all the threads), but they wait until the disks are not busy. I'm not really sure what it would give you to have the nfsd's wait until disk is not as busy, as that is what it is doing now, right? Maybe you would smooth out your spikes a bit, but that's not saying it is running any better. There's no cure for slow block devices, except for more cache, or faster block devices. :) Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?434FED3F.5060907>