From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 21:51:04 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 4260416A410 for ; Wed, 20 Feb 2008 21:51:04 +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 16F2513C4D1 for ; Wed, 20 Feb 2008 21:51:04 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from user-64-9-237-172.googlewifi.com (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 14EC633C59; Wed, 20 Feb 2008 13:51:03 -0800 (PST) Date: Wed, 20 Feb 2008 13:51:02 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Attila Nagy In-Reply-To: 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: Thu, 21 Feb 2008 00:32:32 +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 21:51:04 -0000 At Tue, 19 Feb 2008 20:30:07 -0700, JINMEI Tatuya wrote: > 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). Okay, I've fond handier workaround (that should work for 7.X). Please try the following steps: - create a symbolic link from "/etc/malloc.conf" to "X": # ln -s X /etc/malloc.conf - start named with a moderate limitation of virtual memory size, e.g. # /usr/bin/limits -v 384m $path_to_named/named Then the named process will eventually abort itself with a core dump due to malloc failure. Please show us the stack trace at that point. Hopefully it will reveal the malloc call that keeps consuming memory. Notes: - of course, this is a very radical way of diagnosing; you need to keep watching the process because it's "guaranteed" to be aborted. - the VM size must be carefully chosen so that malloc failure won't happen due to normal named processing. I think 384MB is reasonable enough according to the statistics you provided so far, but I'm not 100% sure about that. - it's better to keep my latest patch to adb.c and to run named with '-n 1' so that the mutex_init in adb.c won't trigger the malloc failure. - the global symbolic link from /etc/make.conf affects other processes. So, if you're running a different process than named that can consume a lot of memory or can cause malloc failure, we should find an alternative approach (there are some, but they are more complicated so let's discuss those only when they are really necessary). Again, thanks for your cooperation. --- JINMEI, Tatuya Internet Systems Consortium, Inc.