dnsperf and BIND memory consumption

[Dmitry Rybin]

Memory statistic
 start -  570M
 1 min -  913M
 2 min -  958M
 3 min - 1092M
 4 min - 1074M
 5 min - 1082M
10 min - 1217M
15 min - 1234M
60 min - 1513M

max-cache-size 800M;

Port installed only with Threads parameter, and patch in Makefile
====
.if (${ARCH} == "amd64")
ARCH=           x86_64
.endif
====

===========================================
# ps axw|grep named
/usr/local/sbin/named -t /var/named -u bind -c /etc/namedb/named.conf -t
/var/named -u bind
===========================================
$ rndc status
version: 9.5.0-P2 (Unknown DNS1)
number of zones: 899
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 2
query logging is OFF
recursive clients: 286/9900/10000
tcp clients: 0/100
server is up and running
===========================================
(port installed)
$ldd /usr/local/sbin/named
/usr/local/sbin/named:
        libcrypto.so.5 => /lib/libcrypto.so.5 (0x807bb000)
        libthr.so.3 => /lib/libthr.so.3 (0x80a4d000)
        libc.so.7 => /lib/libc.so.7 (0x80b63000)

(system standart)
$ldd /usr/sbin/named
/usr/sbin/named:
        libcrypto.so.5 => /lib/libcrypto.so.5 (0x807a9000)
        libthr.so.3 => /lib/libthr.so.3 (0x80a3b000)
        libc.so.7 => /lib/libc.so.7 (0x80b51000)
===========================================

ivan jr sy wrote:
> Hi
> 
> can you verify if you're using the newly installed named.
> 
> did you configure your options to replace the base?
> 
> can you give us:
> 
> ldd /usr/sbin/named
> ldd /usr/local/sbin/named
> 
> to my understanding, there should be no memory leak issue at all if you disable threads..
> 
> this post has always been directed to the concern of FreeBSD + amd64 platform + FreeBSD port dns/bind95 (BIND 9.5.0-P2) + threading enabled
> 
> thanks!
> 
> --- On Wed, 12/10/08, Dmitry Rybin <kirgudu at corbina.net> wrote:
> 
>> From: Dmitry Rybin <kirgudu at corbina.net>
>> Subject: Re: dnsperf and BIND memory consumption
>> To: "Vinny Abello" <vinny at tellurian.com>
>> Cc: "JINMEI Tatuya / 神明達哉" <Jinmei_Tatuya at isc.org>, "dougb at FreeBSD.org" <dougb at FreeBSD.org>, "bind-users at isc.org" <bind-users at isc.org>
>> Date: Wednesday, December 10, 2008, 4:05 AM
>> Hello!
>>
>> I test patch, add to bind95/Makefile
>> .if (${ARCH} == "amd64")
>> ARCH=           x86_64
>> .endif
>>
>> work/bind-9.5.0-P2/config.log
>> uname -m = amd64
>> /usr/bin/uname -p = amd64
>> Target: amd64-undermydesk-freebsd
>> Configured with: FreeBSD/amd64 system compiler
>> ISC_ARCH_DIR='x86_32'
>> build='x86_64-portbld-freebsd7.0'
>> build_alias='x86_64-portbld-freebsd7.0'
>> build_cpu='x86_64'
>> host='x86_64-portbld-freebsd7.0'
>> host_cpu='x86_64'
>>
>> I didn't find any affect, memory leak very quickly with
>> threads support,
>> and slowly without threads.
>>
>> FreeBSD xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul  2
>> 14:18:35 MSD
>> 2008     xxx at xxx:/usr/obj/usr/src/sys/H1  amd64
>>
>>
>> Vinny Abello 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.
>>> Just out of curiosity, why in theory is this not seen
>> in prior versions of BIND such as 9.4.2-P2 or 9.4.3 on the
>> same FreeBSD 7.0 AMD64 platforms with threading enabled in
>> BIND?