From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 03:30:08 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388BB16A405 for ; Wed, 20 Feb 2008 03:30:08 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by mx1.freebsd.org (Postfix) with ESMTP id 2510013C4D3 for ; Wed, 20 Feb 2008 03:30:08 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from user-64-9-233-225.googlewifi.com (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id E9DCF33C59; Tue, 19 Feb 2008 19:30:07 -0800 (PST) Date: Tue, 19 Feb 2008 20:30:07 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Attila Nagy In-Reply-To: <47BAE0B3.4090004@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 20 Feb 2008 04:09:50 +0000 Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 03:30:08 -0000 At Tue, 19 Feb 2008 14:59:15 +0100, Attila Nagy wrote: > > Okay, then please try this patch with '-n 1' (note: this patch doesn't > > contain the memory statistics hack via the HTTP interface, but I don't > > we don't need it for this test). [...] > (max-cache-size still 32M) Hmm, then the mutex locks dynamically generated are also irrelevant. I've also tried to reproduce the problem in a similar environment (BIND 9.5.0b1 with threads on FreeBSD 7.0RC1/AMD64, cache-only configuration, using a real query sample), unsuccessfully. One significant difference is that I disabled SMP in the kernel (it was very unstable with the SMP support for some unknown reason), but I doubt this is the key for the difference of the named behavior. BTW, is this reproduceable on FreeBSD 6.x? If so, then I'd like to see what happens if you specify some small value of datasize (e.g. 512MB) and have named abort when malloc() fails with the "X" _malloc_options. (This option doesn't seem to work for FreeBSD 7.x, at least at the moment). Some other questions: - can we see your named.conf? If you specify non-default configuration options, that might be the reason for, or related to, this problem. - does your named produce lot of log messages? If so, it might also be a reason (simply because it relies on standard libraries). Thanks, --- JINMEI, Tatuya