[nsd-users] Assumed Memory Leak in NSD-3.2.3 ??

Fri Apr 9 15:27:27 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Christian,

We are more than happy to help you with this problem.
What was the version of NSD you used prior to 3.2.3?

I assume you run nsdc patch at a regular interval?

I have some more comments inline.

Best regards,

Matthijs Mekking
NLnet Labs

What was
Christian Petrasch wrote:
> Hello,
> 
> we ( the DENIC eG ) are using your nameserver software NSD now for
> several years.
> After  switching to NSD-3.2.3  we are getting trouble with the memory
> footprint of NSD-3.2.3.
> The memory  consumtion is raising until its physical  limit ist reached,
> then swap is used.
>  After all limits are reached NSD-3.2.3 can't  start an ixfr  anymore.
> 
> It looks like if swapped memory is not freed.
> Starting NSD with one process, NSD forks a second process as usual.
> Then another process is opened. beeing independent from the others.
> I assume the forked process is used to perform the ixfr.
> I don't know the purpose of the independent process.

The 'independent' is indeed the xfr daemon. It will request axfr and ixfr.

> 
> We run our servers on Xen virtual machines using 12 GB of RAM and 10 GB
> Swap.
> The size of our zonefile is about 1.1 GB.
> What size of RAM and swao do you recommend  for a zonefile of this size ?
> In the past, using  NSD-2.1.4,  a RAM size of  8 GB had been sufficient.

The zone in memory is about twice as big in memory then on disk. At most
it can be four times as large. So a RAM of 5 GB should be sufficient.

> Here an output of top of our server after a fresh start:
> 
> top - 15:14:33 up 50 days,  3:15,  2 users,  load average: 0.00, 0.23, 0.34
> Tasks:  61 total,   1 running,  60 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,
>  0.0%st
> Mem:  12582912k total,  6505944k used,  6076968k free,     1088k buffers
> Swap:  9999992k total,   689732k used,  9310260k free,     8348k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 20616 dnsadm    15   0 86632 1612  912 S    0  0.0   0:00.00 sshd
> 20617 dnsadm    15   0 67276 1988  988 S    0  0.0   0:00.01 tcsh
> 20909 dnsadm    15   0 63536  992  836 S    0  0.0   0:00.00 less
> 21936 dnsadm    15   0 86628 1608  912 S    0  0.0   0:00.00 sshd
> 21937 dnsadm    15   0 67268 1984  988 S    0  0.0   0:00.02 tcsh
> 22259 dnsadm    15   0 10704  992  776 R    0  0.0   0:00.15 top
> 22273 dnsadm    16   0 3282m 2.6g  608 S    0 21.3   0:14.30 nsd
> 22284 dnsadm    15   0 3439m 3.3g  412 S    0 27.7   5:40.85 nsd
> 22526 dnsadm    18   0 3439m 3.3g  136 S    0 27.7   0:00.00 nsd
> 
> 
> 
> Here the output of top  approx. 1 week of running:
> 
> top - 14:53:59 up 50 days,  2:54,  2 users,  load average: 0.00, 0.00, 0.00
> Tasks:  61 total,   2 running,  59 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,
>  0.0%st
> Mem:  12582912k total,  9097360k used,  3485552k free,    94196k buffers
> Swap:  9999992k total,  2720028k used,  7279964k free,  1953724k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 19608 dnsadm    15   0 5758m 5.6g  340 S    0 46.5   0:00.84 nsd
> 19609 dnsadm    18   0 5758m 5.6g  136 S    0 46.5   0:00.00 nsd
> 20197 dnsadm    15   0 3282m 704m  616 S    0  5.7   0:14.68 nsd
> 20616 dnsadm    15   0 86632 1624  912 S    0  0.0   0:00.00 sshd
> 20617 dnsadm    15   0 67276 1988  988 S    0  0.0   0:00.01 tcsh
> 20909 dnsadm    15   0 63536  992  836 S    0  0.0   0:00.00 less
> 21936 dnsadm    16   0 86628 1616  912 R    0  0.0   0:00.00 sshd
> 21937 dnsadm    15   0 67268 1984  988 S    0  0.0   0:00.02 tcsh
> 21970 dnsadm    15   0 10704  992  776 R    0  0.0   0:00.00 top
> 
> 
> As You can see, NSD is using a lot of RAM space.
> The longer NSD is running the more memory is allocated until the limit
> is reached having the famous oom-killer (out of memory) inside the
> kernel killing some process.
> 
> There seems to be a memory leak somewhere.
> 
> Can you assist us with this problem ?
> 
> Thank you very much..
> 
> kind regards
> 
> -- 
> Christian Petrasch
> IT-Services
> 
> DENIC eG
> Kaiserstraße 75-77
> 60329 Frankfurt am Main
> GERMANY
> 
> E-Mail: petrasch at denic.de
> Fon: +49 69 27235-429
> Fax: +49 69 27235-239
> http://www.denic.de <http://www.denic.de/>
> 
> PGP-KeyID: 17613DFA, Fingerprint: 791A 40DF 47EF DBBD D8E3 72D0 9A6A
> 846E  1761 3DFA
> 
> Angaben nach § 25a Absatz 1 GenG:
> DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt
> am Main)
> Vorstand: Sabine Dolderer, Marcus Schäfer, Carsten Schiefner, Dr. Jörg
> Schweiger
> Vorsitzender des Aufsichtsrats: Elmar Knipp
> Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht
> Frankfurt am Main

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJLv0dcAAoJEA8yVCPsQCW5yvYIAMzOKpN/yV9NI85k9yg2mW7q
PH/mZfaPVNnVerSWTBQozfNUzW5x8DeBmBWrYjuvA7KupjShTtmiwCBcV9ABK5nd
B6OAKjwo6Oya7kg4wfybqe3Db9HanGn1/pCmEFmmjlYD0rSFBsP1qOKxMRc3y5ec
SLsf5GmILUPa+8p/R3szidOWhdxTHrNlgmScK5UBo+c63gD0C4FrYsietl0Hqs/w
Rb7gi2PV2C27VU59r4zRAedY3Ht1U0wvrdbDZq7LZxAaGYzHk6sfpjMENn5TeVKX
CKsOZ4lC77jiEuW8bHllZTE6XKcwZkknua03Fn99q5b+GoMvMxw2ADGRWCQwdro=
=aQhE
-----END PGP SIGNATURE-----