max-cache-size doesn't work with 9.5.0b1

[JINMEI Tatuya / 神明達哉]

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.

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.