max-cache-size doesn't work with 9.5.0b1
JINMEI Tatuya / 神明達哉
Jinmei_Tatuya at isc.org
Wed Feb 20 21:51:04 UTC 2008
At Tue, 19 Feb 2008 20:30:07 -0700,
JINMEI Tatuya <Jinmei_Tatuya at 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.
- 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
- 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
Again, thanks for your cooperation.
Internet Systems Consortium, Inc.
More information about the freebsd-performance