<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hi Kevin and thanks for the help.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">

Is it possible to upgrade the dnsmasq version on the router without waiting for the author of the tomato firmware to include a later version in a release of his firmware (and you mentioned that dnsmasq in tomato isn't a clean pull of Simon's release)?</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Why would changing the location of the leasefile to a usb stick make a difference? If the issue, as Simon suggests, is caused by the constant rewriting of the lease database, then wouldn't its current location (which on a router would be RAM) be a faster/better option than a usb stick? Or is there another possible issue here that I've missed?</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The only recent change I've made to the router was the addition of a usb stick as the location for the writing of system logs and bandwidth and IP traffic usage logs (so that they weren't lost on a reboot). I had wondered if the cause of the problem was related to the speed of writing this stuff (which obviously includes dnsmasq logging) to the usb stick rather than RAM. That's why I turned off dnsmasq logging at one point but it didn't seem to make any difference.</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks again for your help and I'll wait for your comments on the above.</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Cheers</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br>

</div><div class="gmail_default" style="font-family:tahoma,sans-serif">David</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">

<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 April 2014 21:13, Kevin Darbyshire-Bryant <span dir="ltr"><<a href="mailto:kevin@darbyshire-bryant.me.uk" target="_blank">kevin@darbyshire-bryant.me.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 24/04/2014 20:49, Simon Kelley wrote:<br>
> On 24/04/14 20:41, David Joslin wrote:<br>
>> Thanks for the reply, Simon.<br>
>><br>
>> DNSSEC isn't enabled.<br>
>><br>
>> I wonder if the pattern of the problem gives any clues...<br>
>><br>
>> As I said, on a normal day with around 40-50 clients on the network there<br>
>> is no problem at all with dnsmasq managing to use barely 0 - 2% of the CPU.<br>
>> When the problem occurred there were a little over 100 clients. Running top<br>
>> showed dnsmasq using 100% cpu so I restarted dnsmasq and kept an eye on<br>
>> top. For maybe 5 or 10 minutes there was no problem, with dnsmasq using<br>
>> very little cpu. Then dnsmasq would start to peak at maybe 20-30% for a<br>
>> couple of seconds before dropping back. Then it would start peaking at<br>
>> higher and higher levels before dropping back. Eventually, after running<br>
>> for maybe half an hour it would start peaking at over 90% and staying there<br>
>> for longer before dropping back. At this point dns requests would become<br>
>> very slow (and maybe time out). And then dnsmasq would hit 100% cpu and<br>
>> would stay there. Dns requests would time out and only restarting dnsmasq<br>
>> would fix the problem. The pattern would then start over again.<br>
>><br>
>> I may be wrong but it doesn't seem that dnsmasq is hitting a bug that<br>
>> suddenly causes it to loop and hog the cpu until it's killed. It seems to<br>
>> gradually show more and more of the problem before it eventually hogs 100%<br>
>> cpu and has to be killed.<br>
>><br>
>> If the problem was caused by dnsmasq being overloaded with requests, is it<br>
>> likely or possible that 50 clients could put very little load on it but 100<br>
>> clients could swamp it? Also, would the problem not show itself as soon as<br>
>> dnsmasq was restarted rather than showing the gradual increase in peak<br>
>> usage until it hits 100%?<br>
><br>
> Logs would help. The pattern doesn't look familiar, but if I had to<br>
> guess, I'd say that the problem is DHCP, not DNS. Every change to the<br>
> DHCP lease database causes the file storing it to be re-written, and I<br>
> suspect that's what's eating CPU, in disk wait.<br>
><br>
> Version of dnsmasq in use would be useful, and a copy of your config (to<br>
> me privately, if you prefer.)<br>
><br>
> When dnsmasq is running at 100%, try running<br>
><br>
> strace -p <pid of dnsmasq process><br>
><br>
> that will run forever, printing what syscalls are being made, you can<br>
> ctrl-c it after a show while, which will stop strace, but not dnsmasq.<br>
><br>
><br>
> Cheers,<br>
><br>
><br>
> Simon<br>
><br>
><br>
<br>
</div></div>Chaps,<br>
<br>
Please be aware that the dnsmasq included in tomato is not a clean<br>
'pull' out of Simon's release but includes some tweaks, mainly to the<br>
lease writing code (where it outputs 'remaining leasetime' rather than<br>
expiry time)  There's also a 'helper' function that upon receipt of<br>
SIGUSR1 (or it may be 2 I can't remember) dumps the leasefile in a<br>
tomato specific format so that it may be read & parsed into the 'dhcp<br>
status' page.<br>
<br>
Those changes were 'formalised' by me into IFDEF conditional compilation<br>
flags when I first investigated updating dnsmasq from v2.61 to something<br>
slightly newer which fixed the IPv6 RA flags.  The original changes by<br>
Jon Zarate were identified and re-inserted after a few false starts.  I<br>
am no 'C' coder!<br>
<br>
My suggestion for a start are to upgrade to dnsmasq 2.70 rather than a<br>
test release of 2.69.  Also try changing the location of the leasefile<br>
to somewhere else e.g. a USB stick if your router supports it.<br>
<br>
I've not encountered anything like this but then I don't have 100 clients.<br>
<span class="HOEnZb"><font color="#888888"><br>
Kevin<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
<br></blockquote></div><br></div></div>