Date: Mon, 04 Feb 2008 11:36:56 -0800 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org> To: Attila Nagy <bra@fsn.hu> Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 Message-ID: <m2wspkpl7r.wl%Jinmei_Tatuya@isc.org> In-Reply-To: <47A614E9.4030501@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <m2lk6g71bc.wl%Jinmei_Tatuya@isc.org> <479DFE74.8030004@fsn.hu> <m2k5ltke09.wl%Jinmei_Tatuya@isc.org> <479F02A7.9020607@fsn.hu> <m24pcwt5b7.wl%Jinmei_Tatuya@isc.org> <47A614E9.4030501@fsn.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
At Sun, 03 Feb 2008 20:24:25 +0100, Attila Nagy <bra@fsn.hu> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2wspkpl7r.wl%Jinmei_Tatuya>