[bind10-dev] Thinking aloud: Multi-CPU auth

[Michal 'vorner' Vaner]

Hello

On Mon, Dec 20, 2010 at 03:17:29PM +0100, Shane Kerr wrote:
> > Third, assume the OS has fork (I heard there are systems that lack that
> > powerful tool, though). Auth could start, load all the configuration, data (in
> > case of in-memory data source), bind the sockets and then fork as many times as
> > needed (leaving the parent do nothing). In case the configuration changed, the
> > parent would reload it, kill all the children and fork them again (could do it
> > one by one, so we don't go completely dead). The advantage I see here is both
> > the simplicity and the fact that the in-memory data are there only once, shared
> > between the processes.
> 
> The disadvantage here is that the auth server itself has to do process
> management, which I had hoped to avoid. If there is real benefit in it I
> suppose it is a way forward, but... 

Well, the process management would be easy one I guess. Really compared with
some kind of shared memory (if we have a .com on a machine with 8 processors, we
probably don't want to have 8 copies of the zone in RAM), keeping that in sync,
etc. I think we could get all that by almost free, including faster start (if 8
processes all try to load the large zone file, the disk cache might help, but
might as well not, in which case the 8 processes would fight over the disk
bandwidth).

> > All three of them have slight problems with updating data. If we have some kind
> > of SQLish data source, then it will probably take care of the updates, locking
> > and stuff all by itself. But with the in-memory one, everyone has its own copy.
> > So we either need to signal everyone else, or have it somehow shared. And I'm
> > not sure we can have a shared lock on shared memory (because we want concurrent
> > reads as much as possible). Another way would be that, in case of forking, the
> > parent would do the updates and then restart the children (if there were many
> > changes, it would have to be limited in some way, for example no more often than
> > once every 5 minutes).
> 
> An interesting idea! This actually makes the 3rd option seem potentially
> beneficial. Although all of this will have to be considered with the
> DDNS and related technologies (IXFR, re-signing, and so on).

Yes, right. Batching them for 5 minutes might be too long in some cases (we
would probably need some kind of configuration ‒ if it is just for registering
new zones, 5 minutes is probably OK, if it is for people connecting with laptops
and telling their computer name to the dhcp server, then 5 minutes is probably
long). Or, DDNS asks for immediate update? How much immediate does it have to
be?

Thanks

-- 
Anything is possible, unless it's not.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101220/dc5c9e08/attachment.bin>