dnsperf and BIND memory consumption

[JINMEI Tatuya / 神明達哉]

At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin <kirgudu at corbina.net> wrote:
> 
> JINMEI Tatuya / 神明達哉 wrote:
> > At Tue, 09 Dec 2008 18:05:27 +0300,
> > Dmitry Rybin <kirgudu at corbina.net> wrote:
> > 
> >> I test patch, add to bind95/Makefile
> >> .if (${ARCH} == "amd64")
> >> ARCH=           x86_64
> >> .endif
> > 
> > Future versions of BIND9 will support amd64 in its configure script to
> > workaround the FreeBSD port for amd64.
> > 
> > Regarding the memory leak, I believe it's already solved in 9.5.1rc1
> > (even with threads and without atomic).
> 
> I just make port bind 9.5.1rc1. It has same problem with memory leak.
> It grows from 670M on startup, to 1,4Gb after 20 minutes of work.

Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?

Second, what if you stop named by 'rndc stop'?  If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.

If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-users&m=121811979629090&w=2
 
To summarize it:

1. create a symbolic link from "/etc/malloc.conf" to "X":
   # ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
   # /usr/bin/limits -v 384m $path_to_named/named <command line options>
(note that "384m" should be reasonably large compared with
max-cache-size.  I'd suggest setting max-cache-size to 128M and
setting 'limits -v' to 512m).
3. 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.

In fact, I myself successfully identified one leak in 9.5.0-P2 with
FreeBSD port this way.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.