dnsperf and BIND memory consumption

Vinny Abello vinny at tellurian.com
Tue Dec 2 05:35:32 UTC 2008


Hi,

	For what it's worth, I just want to contribute that I can confirm this behavior on my systems as well. On BIND 9.5.0-P2, building manually outside of ports with threads enabled does not induce the massively noticeable memory leak like it does from the version in ports. The BIND 9.4.2-P2 port is fine though even with threads enabled. I'm currently running off a manually built version of 9.4.3 which resulted in x86_32 for @ISC_ARCH_DIR@ from the configure script on my AMD64 FreeBSD 7.0 systems and also works just fine. Thanks for your additional investigation into this issue, Ivan. Hopefully the root cause is or will be identified and corrected. I'm fine building BIND manually from source. Can someone comment what changes are actually in the versions from the FreeBSD ports tree that differs from the source and what those changes intend to do exactly?

-Vinny

> -----Original Message-----
> From: JINMEI Tatuya / 神明達哉 [mailto:Jinmei_Tatuya at isc.org]
> Sent: Friday, November 28, 2008 4:09 AM
> To: ivan_jr at yahoo.com
> Cc: dougb at FreeBSD.org; Vinny Abello; bind-users at isc.org
> Subject: Re: dnsperf and BIND memory consumption
> 
> At Thu, 27 Nov 2008 23:35:30 -0800 (PST),
> ivan jr sy <ivan_jr at yahoo.com> wrote:
> 
> > so does this memory leak only occur if
> > @ISC_ARCH_DIR@ is "noatomic" under FreeBSD amd64?
> > and not when its "x86_32" ?
> 
> First off, note that I have no explicit evidence of memory leak.  But
> *if there is indeed leak in the FreeBSD pthread library*, the key is
> "noatomic".  With this configuration named will call pthread
> locks/unlocks much, much heavier, so the problem may be observable
> more clearly.  named still uses pthread locks Even with x86_32, so it
> may just be leaking memory more slowly.
> 
> Again, everything is just a guess and could be wrong.  We should seek
> advice from someone who knows FreeBSD library well.
> 
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.



More information about the bind-users mailing list