[Dnsmasq-discuss] [PATCH] Add a flag to customise MAX_PROCS
Petr Menšík
pemensik at redhat.com
Wed Nov 1 12:59:16 UTC 2023
In general I like the change. Fixed number does not scale. I would move
max_procs in dnsmasq right after tcp_pipes. It belongs to it and is
directly related. I would add into comment /* tcp_pipes size */,
because the name does not make it obvious. Maybe even call it
tcp_pipes_sz instead of max_procs. I would use unsigned int as a type,
negative value does not make sense for it anyway.
I think whole TCP handling concept is unfortunate and slow. It allocates
64kB for each TCP socket I think, which is no issue on any today's
hardware. But some old routers may have too little of memory. I may have
mistaken this with avahi, it does it similar way. This is a minimal
change to archieve non-crashing results. I would expect just 4kB buffer
would be enough for almost anything, it should just reallocate the
buffer if that is not enough. But that would require careful changes to
not break anything else.
Even better it should handle TCP inside main process with non-blocking
socket API, without extra forks spawned. But that has to wait.
I recommend using option edns0 inside /etc/resolv.conf on any clients
where it can work, to avoid TCP queries if possible. TCP queries have
worse failover implementation and are much slower than UDP queries.
Anyway, nice change in my opinion.
Cheers,
Petr
On 12. 10. 23 0:36, Damian Sawicki via Dnsmasq-discuss wrote:
> Hello dnsmasq experts,
>
> I'd like to propose a patch adding a flag to customise MAX_PROCS. I
> know this was already suggested in
> https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014907.html
> for other reasons and rejected back then. My motivation is that in
> some use cases in Kubernetes, MAX_PROCS is actually a bottleneck, so
> it would be great to have the possibility to customise this limit
> depending on the load.
>
> Do you think that this patch is enough or would it be good to have
> insight into the utilisation? I've prepared another patch that
> introduces logs with the information on the number of child processes
> (behind a feature flag). Could you please advise?
>
> Please kindly let me know what you think.
>
> Kind regards,
>
> Damian Sawicki
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9098 bytes
Desc: OpenPGP public key
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20231101/d530ef61/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20231101/d530ef61/attachment.sig>
More information about the Dnsmasq-discuss
mailing list