[nsd-users] nsd process restarting

[Franky Van Liedekerke]

Hi,

we've configured a timeout of 15 seconds for xfr. I did see a load
improvement (of course the server never was that loaded to begin with,
but it is calming down and all CPU cycles count :-) )

Franky

On Fri, 2022-09-16 at 13:32 +0200, Jeroen Koekkoek wrote:
> Hi Anand, Franky,
> 
> Just a quick remark on Anand's excelent explanation.
> 
> It's not the child processes that apply updates. Rather, it's the
> main
> server that gets forked, applies the updates and then starts new
> children. If the reload succeeds, the old server and it's children
> are
> killed.
> 
> The reason for this is that it gives us completely lock free database
> access across multiple processes and that greatly improves
> performance.
> This builds on the fork behavior found on UNIX platforms, which
> shares
> the memory between every forked process in a copy-on-write manner. On
> unices, forking is relatively cheap.
> 
> Obviously, if you have lots of zone updates and there are lots of
> restarts, that becomes increasingly expensive. Allowing for a little
> more time between reloads solves that, like Anand stated.
> 
> Best,
> Jeroen
> 
> 
> On Thu, 2022-09-15 at 15:48 +0200, Anand Buddhdev via nsd-users
> wrote:
> > On 15/09/2022 15:28, Franky Van Liedekerke wrote:
> > 
> > Hi Franky,
> > 
> > > So the process restarts to serve freshly updated zones? Is there
> > > any
> > 
> > Yes, kind of. The master creates new child processes, which have
> > the
> > old 
> > zone data in them. These child processes apply the updates to their
> > in-memory copy of the zones, and then take over serving zones from
> > the 
> > previous processes.
> > 
> > > reason to that logic? Because it is indeed a server that serves
> > > more
> > > than 7000 zones with the real masters indeed updating their zones
> > > regularly, and restarting a dns process because a zone was
> > > updated
> > > is a
> > > very costly step ...
> > 
> > Well, there are different ways to apply updates to existing zones,
> > and 
> > the NSD developers chose this one (fork new child processes to
> > apply
> > the 
> > update). Other name servers like BIND and Knot DNS do things
> > differently.
> > 
> > I agree with you that it's not the most efficient way to do things.
> > For 
> > starters, NSD temporarily causes memory usage to double when
> > applying
> > zone updates. So you either have to provision a server with double
> > the 
> > amount of RAM, or play tricks with swap and/or tune the kernel's
> > memory 
> > variables (eg. overcommit) to ensure that fork() doesn't fail.
> > 
> > However, this is how NSD works, so if you're using it, then it's
> > good
> > to 
> > understand it, and tune your server accordingly.
> > 
> > If you feel that the reloads are too frequent, you can slow them
> > down
> > by 
> > adjusting "xfrd-reload-timeout" from the default of 1s to 10s or
> > even
> > higher. This causes the server processes to be restarted less 
> > frequently. The consequence is that more updates are batched
> > together, 
> > and zone updates will not be visible immediately.
> > 
> > Regards,
> > Anand
> > _______________________________________________
> > nsd-users mailing list
> > nsd-users at lists.nlnetlabs.nl
> > https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20220916/1b20f720/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face-smile.png
Type: image/png
Size: 1057 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20220916/1b20f720/attachment.png>