From owner-freebsd-performance@FreeBSD.ORG Mon Feb 4 19:36:57 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 591BD16A418 for ; Mon, 4 Feb 2008 19:36:57 +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 46FFC13C459 for ; Mon, 4 Feb 2008 19:36:57 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from dhcp-182.sql1.isc.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 4163633C59; Mon, 4 Feb 2008 11:36:56 -0800 (PST) Date: Mon, 04 Feb 2008 11:36:56 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Attila Nagy In-Reply-To: <47A614E9.4030501@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@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: Mon, 04 Feb 2008 19:45:29 +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: Mon, 04 Feb 2008 19:36:57 -0000 At Sun, 03 Feb 2008 20:24:25 +0100, Attila Nagy wrote: > Yes, if bind was built with threads, the memory usage always grew behind > max-cache-size very quickly. > > Here is the log: > http://people.fsn.hu/~bra/freebsd/bind950-memory-20080203/bind950b1 > the memory usage (RSS, reported by top) in megabytes: > 19:10:37 466 > 19:11:20 522 > 19:11:53 566 > 19:13:06 666 > 19:14:17 766 > > max-cache-size was set to 64M. Hmm. According to the log message, named seems to control the cache memory pretty well so that it doesn't exceed max-cache-size. So, the memory hog should be somewhere else. One obvious explanation is memory leak, of course. If it occurs within named, you should be able to find it by stopping the daemon (memory leak will trigger assertion failure). Another possible scenario is that you're being hit by known memory leak in the built-in statistics HTTP server (unfortunately, this isn't caught by assertion). If you've enabled the feature and are retrieving statistics via HTTP at a very high rate, your server will possibly eat memory avariciously. I actually suspect that this is NOT the likely cause in this case, from the very rapid growth you showed, but if you enable the built-in HTTP server, could you turn it off and try again? BTW, this leak will be fixed in 9.5.0b2. Finally, at the risk of pointing a finger at someone else who's innocent, is it possible that there's leak in FreeBSD's thread library? For example, busy BIND9 caching servers frequently create and destroy mutex locks; if the thread library fails to cleanly free memory for mutex's, the server memory will grow rapidly. p.s. I'm afraid the patch Mark provided in his response won't solve this particular problem from the information we've got so far. --- JINMEI, Tatuya Internet Systems Consortium, Inc.