dnsperf and BIND memory consumption

[Vinny Abello]

> -----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.

OK. I've recompiled BIND 9.5.0-P2 (from ports) without threads enabled. I no longer see the memory leak at all. I'm running dnsperf and I see a constant of 18MB which is much more reasonable for what I am doing. For me it's easy to reproduce. Some more information that may help reproduce it:

FreeBSD 7.0 STABLE AMD64 (cvsup'ed within the past week)
BIND 9.5.0-P2 installed via ports with threads enabled
Server is a Dell PowerEdge 2850 with 2 CPU's, Hyperthreading disabled, 4GB of RAM and a 36GB RAID1 array on a Perc4 controller (LSI MegaRAID chipset)
Dnsperf run from a different server on the same network segment over Gig-E

Interestingly, without threads I am seeing pretty much the same performance as with threads, but am only using one CPU and now have extra horsepower to spare. I know the maintainer of the BIND95 port on FreeBSD enabled threads by default, but I'm wondering if this should be reconsidered... that's more of an issue for a FreeBSD list, but if something is figured out, I can point the port maintainer to this thread (unless he's reading it already).


I saw Danny state that Windows just had a fix made in regards to a memory leak specific to Windows socket code, but I'm wondering if what I was seeing was related to threads on Windows as well. I guess it's hard to tell without the fixed socket code to test with. I would recommend playing with dnsperf though to see if ISC can reproduce this with threads enabled.

-Vinny