dnsperf and BIND memory consumption

Vinny Abello vinny at tellurian.com
Wed Aug 27 01:26:07 UTC 2008


> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Vinny Abello
> Sent: Saturday, August 09, 2008 3:21 PM
> To: JINMEI Tatuya / 神明達哉
> Cc: bind-users at isc.org
> Subject: RE: dnsperf and BIND memory consumption
>
> > -----Original Message-----
> > From: JINMEI Tatuya / 神明達哉 [mailto:Jinmei_Tatuya at isc.org]
> > Sent: Thursday, August 07, 2008 12:38 AM
> > To: Vinny Abello
> > Cc: bind-users at isc.org
> > Subject: Re: dnsperf and BIND memory consumption
> >
> > At Thu, 7 Aug 2008 00:26:04 -0400,
> > Vinny Abello <vinny at tellurian.com> wrote:
> >
> > > Huh... maybe I was right in the first place. I left dnsperf running
> > > and named ran out of memory. In my syslog I had a lot of these
> > > swap_pager_getswapspace failed messages followed by named finally
> > > dying (again, FreeBSD 7.0 STABLE AMD64, 4GB of RAM and the only
> > > software running is really BIND).
> >
> > Quick questions: did you enable threads?  If so, does that change if
> > you disable threads?  We've heard a similar report on a beta version
> > of 9.5.0 for FreeBSD, which reportedly only happened with enabling
> > threads (and only happened with 9.5, not 9.4).  I've tried to
> > reproduce it with a mostly equivalent setting of OS/hardware, but
> > never succeeded in seeing it by myself.
>
> Just an update on some additional data I have on this. I saw your
> previous thread on this issue where you ran without SMP compiled into
> the kernel and could not reproduce the problem. Just to be sure and
> eliminate that, I recompiled my kernel without SMP support, but I still
> saw the leak with threads compiled into BIND.
>
> I instead tried switching to BIND 9.4.2-P2 instead of BIND 9.5.0-P2
> with threads enabled and I am have no memory leak problems at all with
> 9.4.2-P2. For now I am going to stick with this as everything seems to
> be working perfectly. I wanted to try and get you more information on
> the BIND 9.5.0-P2 memory consumption, but I don't have enough
> experience in getting the data you wanted. I'm fairly confident if you
> setup a FreeBSD 7.0 AMD64 system and install the BIND 9.5.0-P2 port,
> you'll see the same problem. That's practically all that I did to see
> the problem. The server does nothing else and was just recently built
> for this purpose. If you have more information on how to get the data
> you were looking for, I can try it on another server for you.
> Alternately I could probably even give you shell access to a machine on
> which I can create this problem. Let me know. I'd be happy to help.

I received the following message from someone with some possible insight to what could be causing this. I have no knowledge of the BIND source code or structure, nor have I looked for the call this is referring to in the source code, so I'm just passing this on for possible research by ISC to see if it possibly applied to FreeBSD threading and if it may be the solution to the memory leak that's been observed by some people in BIND 9.5 on certain operating systems.


Hello Vinny,

I was reading an archive of the BIND Users list today, and I noticed
that you were trying to debug a problem with threads and BSD in BIND.
I thought that I would pass on to you a bug which I have seen, which
may be the same bug.

In the zebedee source code (available from winton.org or sourceforge),
there is the following:

/*
** prepareToDetach
**
** This routine is necessary only on systems which have problems in
** calling "makeDetached". FreeBSD is one such system because of a
** bad interaction between fork and running threads.
*/

void
prepareToDetach(void)
{
#if defined(HAVE_PTHREADS) && defined (BUGGY_FORK_WITH_THREADS)
     pid_t pid;
     int status = 0;


     /* Fork now -- child returns immediately, parent carries on here */

     if ((pid = fork()) == 0) return;

     /*
     ** The parent now waits for the child or to be sent the SIGUSR1
     ** signal. This indicates that the parent should just exit and
     ** leave the child detached.
     */

     fclose(stdin);
     fclose(stdout);
     fclose(stderr);

     signal(SIGUSR1, sigusr1Catcher);
     waitpid(pid, &status, 0);

     exit(status);
#endif
}

My understanding of this code is that it is necessary to avoid leaking
resources during a fork on FreeBSD (and possibly other OSes), but the
problem only happens if threads are enabled.  I do not know how often
BIND forks, but it sounds like it could be exactly the same bug.

Neil Winton may be able to explain this better, I believe that he wrote
that piece of code.  Feel free to forward this email to Jinmei
(including my email address if you wish), but please do not publish my
email on the BIND Users list (I get enough spam as it is).


More information about the bind-users mailing list