From owner-freebsd-net@FreeBSD.ORG Tue Jun 19 13:58:05 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08AA016A41F for ; Tue, 19 Jun 2007 13:58:05 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id B48DF13C483 for ; Tue, 19 Jun 2007 13:58:04 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 28765 invoked from network); 19 Jun 2007 08:31:23 -0500 Received: from 210-84-48-213.dyn.iinet.net.au (HELO localhost) (210.84.48.213) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Jun 2007 08:31:22 -0500 Date: Tue, 19 Jun 2007 23:31:19 +1000 From: Norberto Meijome To: Joe Holden 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> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "M. Warner Losh" , net@freebsd.org Subject: Re: Issue with huge numbers of connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2007 13:58:05 -0000 On Sun, 17 Jun 2007 19:06:16 +0100 Joe Holden 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.