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

[Shane Kerr]

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