Date: Tue, 19 Jun 2007 23:31:19 +1000 From: Norberto Meijome <freebsd@meijome.net> To: Joe Holden <joe@joeholden.co.uk> Cc: "M. Warner Losh" <imp@bsdimp.com>, net@freebsd.org Subject: Re: Issue with huge numbers of connections Message-ID: <20070619233119.1ff6a8e6@localhost> In-Reply-To: <46757818.5030005@joeholden.co.uk> References: <20070617.114133.778151882.imp@bsdimp.com> <46757818.5030005@joeholden.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Jun 2007 19:06:16 +0100 Joe Holden <joe@joeholden.co.uk> wrote: > kern.ipc.nmbclusters FWIW, this one in particular ( controls mbuf clusters) will made a huge difference back in the FBSD 4 days on very heavily used websites. I've had them tuned up to the order of almost 100K - over that they would lock up on boot - the lock ups don't seem to happen anymore on 6, but YMMV. BTW, when the servers I used to run experienced mbuf exhaustion, the machines / OS would still be operational, but nothing would happen at the network layer. A reboot was the only solution I found at the time. P Jeremy made a v. good point about the timeouts of the close states - bring everything down to the minimum that makes sense to your app - the defaults are horribly "kind" to lazy/slow clients :P Service specific configurations may also affect how your resources are used (for example, dont use HTTP keep alives as they hog priceless resources). I know, pretty obvious, but might as well mention it. B _________________________ {Beto|Norberto|Numard} Meijome "But I don't have to know an answer. I don't feel frightened by not knowing things, by being lost in the mysterious universe without having any purpose, which is the way it really is, as far as I can tell, possibly. It doesn't frighten me." Richard Feynman I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070619233119.1ff6a8e6>