[Dnsmasq-discuss] Dnsmasq on high load

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 16/03/15 16:07, Rick Jones wrote:
> 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."

Not generally possible - there's one packet buffer and dnsmasq has to
either answer a request or forward it upstream before it can handle
the next - this code tries to be small in resource use.

> Another would be to simply drop the request outright (non-Linux
> stacks likely would have done so anyway and not necessarily told
> the caller).

That's actually what happens, I suspect it it didn't get logged, this
would probably not have been noticed.

> 
> 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" :)

It would be good to hear from the OP if the fix to the retry code I
posted has cured this.


Cheers,

Simon.

> 
> rick
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVCKTwAAoJEBXN2mrhkTWiVzkP/jEqW42phv0/o3bzx6jBRCuI
hY94NV04RwDuqErkyaTo3vk8ro+LAF5MNsxrpLmZiESLRvm4kxkYmwHyDB2hbXrS
zqGwqZ3syIZ0eoL5NVdIrf36Cbl2Bprh/9CYoemll2cHW3vx+l8IFG0efopMvsqo
tcCTAfPXdNgms49ZiqODW2cdLzQhJ33KKjeyph5GV7zDr83NzEqQukQzTQ8MNGRB
UvEjCRTBwEX/MQIaPVCIagTXRnUGeM6/i4OFu3oaWF0/tPZDG544peFaPEw22qdL
yEMlP/hAFipzBgQx16dE3SzaJVZ4Af3FBRX4kGKVTfXOZNZ7GvgkO8ngP/jQoDO1
dxR7mMEPPLdKqerZJ33g0d4HQTQlHvUeXFPAiJINKLzCsoVME3VIOKbOnDO7LC6A
9v7Ob9iWKqTZjCkwsH8yh9Jc0CwS274nWIDoqJjxNrLJGUqgF9Wi+8N014WNtsEZ
E31WpyqBZv3awkGbhKUi6oxAjFGq/b7Vl5TmKzCVQAImuDfaSj3cw6Mo5pQFYjTW
i1J6rVRHplA2RkW8N+Ioai4ySx1LvFexSZX/zEdBc7zBucI62gdwEfheE37COAkD
hfjE2ljfzjwuUTME1RTTczxNXTdsHoyUqi0OAgQ/pxsRnS0Y85+3b5PggQuYNvI0
C8UgUXqVoDNFMYfi6K/f
=1U99
-----END PGP SIGNATURE-----