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

[Christian Petrasch]

Shane,

thank you for your informations. I will test the option with additional 
nsd-patch commands and will trigger the executes to every hour.
The Problem with the other way you proposed to me isn't an option for us 
sorry, cause we have configurated nsd to runonly  with a 
server count of 1. So we can't reduce it anymore ;) .

I will also take more top snapshots for statistics after the nsd-patch, 
maybe i can recognize  sth new in this strange behavior.

thank you

kind regards

Christian






Von:    Shane Kerr <shane at isc.org>
An:     Christian Petrasch <petrasch at denic.de>
Kopie:  Matthijs Mekking <matthijs at NLnetLabs.nl>, nsd-info at NLnetLabs.nl, 
Jürgen Geinitz <geinitz at denic.de>, Wolfgang Kriegleder 
<kriegleder at denic.de>, nsd-users at NLnetLabs.nl, labs at NLnetLabs.nl, Elmar 
Bins <bins at denic.de>
Datum:  12.04.2010 15:34
Betreff:        Re: [nsd-users] Assumed Memory Leak in NSD-3.2.3 ??



Christian,

> old
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> > 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 
> 
> 6,6 GB + 2,6 Gb = 9,2 Gb 
> 
> new 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
> 18025 dnsadm    15   0 3709m 3.6g  332 S    0 29.9   0:00.44 nsd 
> 18026 dnsadm    18   0 3709m 3.6g  136 S    0 29.9   0:00.00 nsd 
> 22273 dnsadm    15   0 3282m 2.4g  616 S    0 20.0   0:14.31 nsd 
> 
> 7,2 Gb + 2,4 Gb = 9,6 Gb 
> 
> 
> Do you have any ideas ? 

For a large zone (I'm assuming .DE), IXFR can cause nsd processes to
grow quite a bit. You can't compare the resident size at random points
in time - you really need to look at the size of the process after the
"nsdc patch" is performed.

Notice how the parent process (PID 22273) has the exact same size? Also
note that the process ID for the other processes is different? NSD
executes a sort of restart after "nsdc patch" is complete, so it doesn't
make sense to talk about a memory leak in the traditional sense.

You a few options.

One option is to run "nsdc patch" more often. Yes, it's not a very good
answer, since then you end up spending tons of CPU time compacting out
your ixfr.db instead of actually answering queries. (We did this on half
of the machines that I was using, since it took about 5 minutes to run
"nsdc patch" we could do it every hour.)

Another option is to run fewer concurrent NSD processes. The NSD
multi-CPU model consumes a lot more memory per concurrent process. This
is also not a great answer, since it limits your concurrency, but it is
better than swapping (I've been there, I know). (We did this on the
other half of the machines, since "nsdc patch" on them took like 40
minutes.)

Personally I think the IXFR support needs a fundamental rework, if NSD
is going to work smoothly in large zones. Good luck!

--
Shane


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20100412/8388fc26/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6784 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20100412/8388fc26/attachment.bin>