<font size=2 face="sans-serif">Shane,</font>
<br>
<br><font size=2 face="sans-serif">thank you for your informations. I will
test the option with additional nsd-patch commands and will trigger the
executes to every hour.</font>
<br><font size=2 face="sans-serif">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 </font>
<br><font size=2 face="sans-serif">server count of 1. So we can't reduce
it anymore ;) .</font>
<br>
<br><font size=2 face="sans-serif">I will also take more top snapshots
for statistics after the nsd-patch, maybe i can recognize sth new
in this strange behavior.</font>
<br>
<br><font size=2 face="sans-serif">thank you</font>
<br>
<br><font size=2 face="sans-serif">kind regards</font>
<br>
<br><font size=2 face="sans-serif">Christian</font>
<br>
<br><font size=2 face="sans-serif"><br>
<br>
</font>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">Von:
</font><font size=1 face="sans-serif">Shane Kerr <shane@isc.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">An:
</font><font size=1 face="sans-serif">Christian Petrasch
<petrasch@denic.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Kopie:
</font><font size=1 face="sans-serif">Matthijs Mekking <matthijs@NLnetLabs.nl>,
nsd-info@NLnetLabs.nl, Jürgen Geinitz <geinitz@denic.de>, Wolfgang
Kriegleder <kriegleder@denic.de>, nsd-users@NLnetLabs.nl, labs@NLnetLabs.nl,
Elmar Bins <bins@denic.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Datum:
</font><font size=1 face="sans-serif">12.04.2010 15:34</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Betreff:
</font><font size=1 face="sans-serif">Re: [nsd-users]
Assumed Memory Leak in NSD-3.2.3 ??</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Christian,<br>
<br>
> old<br>
> > PID USER PR NI VIRT RES
SHR S %CPU %MEM TIME+ COMMAND<br>
> > 22273 dnsadm 16 0 3282m 2.6g 608 S
0 21.3 0:14.30 nsd<br>
> > 22284 dnsadm 15 0 3439m 3.3g 412 S
0 27.7 5:40.85 nsd<br>
> > 22526 dnsadm 18 0 3439m 3.3g 136 S
0 27.7 0:00.00 nsd <br>
> <br>
> 6,6 GB + 2,6 Gb = 9,2 Gb <br>
> <br>
> new <br>
> PID USER PR NI VIRT RES
SHR S %CPU %MEM TIME+ COMMAND <br>
> 18025 dnsadm 15 0 3709m 3.6g 332 S
0 29.9 0:00.44 nsd <br>
> 18026 dnsadm 18 0 3709m 3.6g 136 S
0 29.9 0:00.00 nsd <br>
> 22273 dnsadm 15 0 3282m 2.4g 616 S
0 20.0 0:14.31 nsd <br>
> <br>
> 7,2 Gb + 2,4 Gb = 9,6 Gb <br>
> <br>
> <br>
> Do you have any ideas ? <br>
<br>
For a large zone (I'm assuming .DE), IXFR can cause nsd processes to<br>
grow quite a bit. You can't compare the resident size at random points<br>
in time - you really need to look at the size of the process after the<br>
"nsdc patch" is performed.<br>
<br>
Notice how the parent process (PID 22273) has the exact same size? Also<br>
note that the process ID for the other processes is different? NSD<br>
executes a sort of restart after "nsdc patch" is complete, so
it doesn't<br>
make sense to talk about a memory leak in the traditional sense.<br>
<br>
You a few options.<br>
<br>
One option is to run "nsdc patch" more often. Yes, it's not a
very good<br>
answer, since then you end up spending tons of CPU time compacting out<br>
your ixfr.db instead of actually answering queries. (We did this on half<br>
of the machines that I was using, since it took about 5 minutes to run<br>
"nsdc patch" we could do it every hour.)<br>
<br>
Another option is to run fewer concurrent NSD processes. The NSD<br>
multi-CPU model consumes a lot more memory per concurrent process. This<br>
is also not a great answer, since it limits your concurrency, but it is<br>
better than swapping (I've been there, I know). (We did this on the<br>
other half of the machines, since "nsdc patch" on them took like
40<br>
minutes.)<br>
<br>
Personally I think the IXFR support needs a fundamental rework, if NSD<br>
is going to work smoothly in large zones. Good luck!<br>
<br>
--<br>
Shane<br>
<br>
</font></tt>
<br>