dnsperf and BIND memory consumption

Vinny Abello vinny at tellurian.com
Sun Aug 10 05:12:41 UTC 2008


> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of JINMEI Tatuya / ????
> Sent: Thursday, August 07, 2008 2:19 PM
> To: Vinny Abello
> Cc: bind-users at isc.org
> Subject: Re: dnsperf and BIND memory consumption
>
> At Thu, 7 Aug 2008 10:33:25 -0400,
> Vinny Abello <vinny at tellurian.com> wrote:
>
> > >
> =======================================================================
> > > - create a symbolic link from "/etc/malloc.conf" to "X":
> > >  # ln -s X /etc/malloc.conf
> >
> > What exactly is this trying to accomplish here? JFYI, I don't have a
> file /etc/malloc.conf on my server. Did you mean /etc/make.conf? Where
> is X being referenced?
>
> /etc/malloc.conf normally doesn't exist.  You should create a new
> symbolic link.  For other details, see malloc(3).
>
> > > - 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.
> >
> > How would I show the trace that you require once this happens?
>
> named will die with a core file.  Then perform the following:
>
> # gdb <path_to_named> <path_to_core>
> (gdb) thread apply all bt full

Apparently I got halfway there. I stumbled across the core file a while ago which I didn't realize was created, but had already downgraded so no longer had the original binary to use with gdb. I'll try this on another machine that I will be setting up. I think I should be able to get this data now.

-Vinny


More information about the bind-users mailing list