From owner-freebsd-performance@FreeBSD.ORG Fri Apr 4 14:34:56 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 22D5C106564A for ; Fri, 4 Apr 2008 14:34:56 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id D190D8FC1A for ; Fri, 4 Apr 2008 14:34:55 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from japan.t-online.private (people [192.168.2.4]) by people.fsn.hu (Postfix) with ESMTP id 7C170B2E06; Fri, 4 Apr 2008 16:34:43 +0200 (CEST) Message-ID: <47F63C82.7060502@fsn.hu> Date: Fri, 04 Apr 2008 16:34:42 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.12 (X11/20080326) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= 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> <47F4F63E.80703@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 04 Apr 2008 14:34:56 -0000 On 04/03/08 19:46, JINMEI Tatuya / 神明達哉 wrote: > Hmm, this is odd in two points: > 1. the "X" malloc option doesn't seem to work as expected. I expected > a call to malloc() should trigger an assertion failure (within the > malloc library) at a much earlier stage. Does it change if you try > the alternative debugging approach I mentioned before? That is: > - 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 > > 2. Whether it's related to this max-cache-size issue, the assertion > failure in mem.c wasn't an expected result; this is likely to be a > bug anyway. If the process dumped a core, can you show the > stack backtrace of it? > (gdb) thread apply all bt full > > No effect, the process grows happily. I don't have a core dump. > This means about 31 log messages per second. This may not be > extremely frequent, but if some memory is lost for every log message, > I guess it could be a reason for the growing memory at the hight rate > we've seen. > > What if you change the channel setting from: > > I've added this, so now the server doesn't log much (after start, noting): category default { null; }; The memory usage still grows. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/