From owner-freebsd-stable@FreeBSD.ORG Thu Oct 4 16:21:48 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E32E16A478 for ; Thu, 4 Oct 2007 16:21:48 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 178F513C457 for ; Thu, 4 Oct 2007 16:21:47 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from epia-2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id B0CD9DF54C; Thu, 4 Oct 2007 18:05:24 +0200 (CEST) Date: Thu, 4 Oct 2007 18:05:22 +0200 From: cpghost To: "Artem Kuchin" Message-ID: <20071004180522.3a724868@epia-2.farid-hajji.net> In-Reply-To: <009201c8069d$2f3edc20$0c00a8c0@Artem> References: <02d401c805cb$abf59ec0$0c00a8c0@Artem> <200710041232.l94CWd6W056143@lurza.secnetix.de> <20071004143944.GA46491@nowhere> <009201c8069d$2f3edc20$0c00a8c0@Artem> Organization: Cordula's Web X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG, Craig Boston Subject: Re: Quation about HZ kernel option X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 16:21:48 -0000 On Thu, 4 Oct 2007 19:42:33 +0400 "Artem Kuchin" wrote: > Craig Boston wrote: > > On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote: > >> In that case, I would recommend not to override the > >> default at all (which is 1000). > > > > ISTM that it would be better to use kern.hz=100 in this case. > > > > My reasoning is that a web server shouldn't be terribly sensitive to > > latency, so it's better to have longer quantums to get more work > > done without context switching overhead. If you're not using > > polling, you'll be getting interrupts for network traffic anyway. > > That what i personally thought. However 100 seems to be too rough. > I just feel so, no reasoning behind this ;) > Maybe 200-300 is better than 100 and better than 1000? > I wonder how to build a test case for this to find best settings for > web server, so others will not stuggle with this on the future. Why would 100 Hz be too rough? Up until recently, very big high traffic web servers were running just fine at 100Hz and some still do today. As Craig said, it's even better to keep the quantum long, so that more work can be done. It makes sense to get rid of client requests as soon as possible, and this is easier done with 100Hz than with higher clock rates. And since context switching happens much more frequently than that (at every blocking syscall, including disk- and network I/O), the server will still be very much responsive anyway. AFAICS, polling(4) is the only scenario where a faster clock makes sense on a web server, and if you absolutely have to do polling, anything below 800Hz to 1000Hz wouldn't make sense anyway. -cpghost. -- Cordula's Web. http://www.cordula.ws/