On 28/06/11 23:25, Richard Zulu wrote:
> Amos,
> Yes, you are right!
> My internal DNS Stats are as follows:
> Nameservers:
> IP ADDRESS # QUERIES # REPLIES
> ---------------------------------------------- --------- ---------
> xxx.xxx.xxx.xx 51219 46320
>
> You realise there is quite a big lap between the queries and replies.
>
> Other than the NAT errors, queue length errors, and large url warnings
> in the config file, I cannot seem to pinpoint why my server develops a
> long queue and cannot get most of it's queries resolved by the DNS.
> DNS is working well for other squid servers. Shifting users from the
> failing squid server to another functioning squid server causes the
> functioning squid server to experience the same issues.
Sure sign that something they are doing is leading to DNS overload.
Things to do:
* reduce dns_timeout, current recommended is now 30 seconds. That will
not resolve the DNS breakage, but will hopefully reduce waiting queries
a lot.
* check your config for things which cause extra DNS lookups:
srcdomain or dst ACLs. "log_fqdn on". small ipcache size.
* try turning "via on" if you have it disabled. See what happens.
"off" can hide bad looping problems.
* maybe look at the most popular sites and see how fast the DNS
response for AAAA and A lookups are.
>
> What is interesting though, is that no sooner have I started my squid,
> than I get queue congestion warning and numerous NAT warnings.
>
Okay. NAT warnings is a side effect of NAT being done on the other box.
Is a seecurity vulnerability and speed slowdown on accepting new
requests. But otherwise is a separate issue. It will be a little bit of
work to fix, so I think we put it asside for now.
AIO queue congestion is normal on a proxy with many users after startup,
so long as it goes away with increasingly rare messages everything is fine.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.12 Beta testers wanted for 3.2.0.9 and 3.1.12.3Received on Tue Jun 28 2011 - 12:47:32 MDT
This archive was generated by hypermail 2.2.0 : Wed Jun 29 2011 - 12:00:02 MDT