Date: Wed, 20 Feb 2008 13:51:02 -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: <m2skzns3eh.wl%Jinmei_Tatuya@isc.org> In-Reply-To: <m2pruse24g.wl%Jinmei_Tatuya@isc.org> 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> <m2wspkpl7r.wl%Jinmei_Tatuya@isc.org> <47A77A13.6010802@fsn.hu> <m2zlueohxk.wl%Jinmei_Tatuya@isc.org> <47B1D2F4.5070304@fsn.hu> <m2tzkexdo7.wl%Jinmei_Tatuya@isc.org> <47B2DD62.6020507@fsn.hu> <m2abm4y4by.wl%Jinmei_Tatuya@isc.org> <47BAE0B3.4090004@fsn.hu> <m2pruse24g.wl%Jinmei_Tatuya@isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Tue, 19 Feb 2008 20:30:07 -0700, JINMEI Tatuya <Jinmei_Tatuya@isc.org> 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 <command line options> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2skzns3eh.wl%Jinmei_Tatuya>