[Dnsmasq-discuss] Dnsmasq on high load

[Rick Jones]

On 03/15/2015 02:06 PM, Simon Kelley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/03/15 00:15, Rick Jones wrote:
>> Does dnsmasq make any setsockopt(SO_SNDBUF) settings?  Perhaps the
>> SO_SNDBUF has filled thanks to Linux's intra-stack flow-control and
>> an attempt to (non blocking?) send has triggered the EAGAIN?
>>
>> Just guessing,
>>
>
> No, it doesn't change the buffer size. I think your guess may be a
> good one.
>
>
> I wonder some adaptive buffer-size expansion could be created?

Presumably, these are transient conditions right?  I suppose there are a 
few choices - one would be to queue the request internally and send it 
again "later."  Another would be to simply drop the request outright 
(non-Linux stacks likely would have done so anyway and not necessarily 
told the caller).

The third would be to tweak the SO_[SND|RCV]BUF explicitly.  Under Linux 
for that to "take" the administrator will have to have tweaked 
net.core.[rw]mem_max.  Otherwise Linux will silently cap any request 
above that value.

As for how much buffer, I suppose for the SO_SNDBUF decision it would be 
how much delay is one willing to add.  Then figure how many sends could 
be drained by the NIC in that length of time.  If the Linux version is 
new enough, it may already have fq_codel employed as the default qdisc 
and there may already be a fair bit of buffering below the socket buffer.

If there are UDP receive errors being recorded (ie because dnsmasq 
wasn't keeping-up with the incoming requests) then the computation would 
be just how long one might reasonably expect a dnsmasq process to remain 
blocked by something else and compute from there.

Lots of choices and "it depends" :)

rick