[Dnsmasq-discuss] Warning when maximum number of concurrent DNS queries is reached

Simon Kelley simon at thekelleys.org.uk
Fri May 31 11:51:41 BST 2013


On 30/05/13 23:16, Marcelo Salhab Brogliato wrote:
> Simon,
>
> The default value for maximum number of forward is 150 and the
> servers was receiving much more than that (I guess it was between 200
> and 300 requests). Thus, many requests were very slow (probably due
> to a long queue) and some were expiring time limit. Changing the
> limit to 500 forwards fixed my problem. So, I guess some logging
> would improve the time I took to diagnose and fix it.

That makes perfect sense.

>
> Totally agree with rate limit in log messages. I'll take a look into
> the code and try to do it.

It turns out to be very simple. Your patch, with rate limiting added, is 
in the git repo now.

Many thanks.

Cheers,

Simon.


>
> Cheers,
>
> -- msbrogli
>
> On May 30, 2013, at 06:29 , Simon Kelley<simon at thekelleys.org.uk>
> wrote:
>
>> On 30/05/13 01:41, Marcelo Salhab Brogliato wrote:
>>> Dear,
>>>
>>> Today I had a problem on my DNS server because it reached the
>>> maximum number of concurrent DNS queries. It was "hard" to
>>> discover the cause of the problem because there is no log that it
>>> have happened. I took a look at the code and this log is really
>>> missing and I guess it is very important.
>>>
>>> Follow my suggestion of improvement for problem detection
>>> purpose.
>>>
>>> Version: 2.52 Patch: --- forward.c.original	2013-05-29
>>> 21:34:13.836999570 -0300 +++ forward.c	2013-05-29
>>> 21:34:22.837164945 -0300 @@ -1007,6 +1007,7 @@ { if (oldest&&
>>> wait) *wait = oldest->time + (time_t)TIMEOUT - now; +
>>> my_syslog(LOG_WARNING, _("Maximum number of concurrent DNS
>>> queries reached (max: %d)"), daemon->ftabsize); return NULL; }
>>>
>>> What do you think about it?
>>>
>>
>> It's many years since this was last looked at.
>>
>> This code used to to log an error and drop the query. The logging
>> was removed when it was changed to not accept new queries when the
>> forwarding table is full. The idea is that the UDP packets are
>> queued in the kernel until resources become available.
>>
>> I'm interested to know about the problem you had: this is supposed
>> to be handled without drama.
>>
>> I'm happy in principle to add logging, but some rate-limiting may
>> be required. Note that get_new_frec() is called for two purposes:
>> from the forwarding path to actually allocate a record, and from
>> the select() loop, where it just discovers is the table is full or
>> not, and calculates how long it will be until space is available.
>> The second could be responsible for a lot of calls and a lot of log
>> messages.
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>>
>> _______________________________________________ Dnsmasq-discuss
>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
>




More information about the Dnsmasq-discuss mailing list