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