dnsperf and BIND memory consumption

[Danny Mayer]

Vinny Abello wrote:
>> -----Original Message-----
>> From: JINMEI Tatuya / $B?@L at C#:H(B [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.

dnsperf was used to test the Windows code and was instrumental in 
detecting the problem. Since the sockets code leak was fixed there are 
no memory leaks seen.

Danny