On 19/09/2012 7:04 p.m., Fran Márquez wrote:
Hi friends,
I have a weird problem of saturation due to a broken client and I don't
know how fix it (I can force user to disable the app who cause the
problem, but I think that should be a solution for avoid that a bad
client can overload the server and affect to proxy service by itself).
Welcome to the real world. Software all has capacity limits. Someone is
performing a *DoS* on your proxy using an internal link with higher
capacity than your service software. What do you do about that?
* close the hole (fix the app, disable it)
* lower the clients service capacity (QoS limit them)
* raise your software capacity (polish your squid.conf for
performance, and add a blacklist on that apps requests to reject then
with a 403 instead of 407)
... then re-evaluate whether they are a problem.
Hint: the faster your Squid responds the faster they will retry. Unless
you manage to get Squid response capacity to be greater than the load
facing it. Thus the QoS kind of appears to work even if it does not
solve anything.
I have found a person who have same problem (here:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-memory-issue-td3044458.html)
but not solution is provide in that thread.
The problem is that some Nokia application try to access to an URL, it
receive 407 error and try again ad infinitum. This cause high load after
few minutes and I need restart the squid/dansguardian services for
restore the correct load of my server.
This problem affect to snmp daemon (who works through squid to do some
checks) and also cause NTLM auth problem.
Er. yes. Maybe NTLM is a large part of the real problem and this is a
side-effect?
Hint: if the NTLM auth helper is being contacted the client *is* sending
NTLM labeled credentials which need to be checked by it. The start 407
message of the NTLM handshake is just the proxy saying it supports NTLM.
A client which responded by re-trying without any credentials would
simply get the same response back with no load on the helper.
Info about my proxy server:
---------------------------
Centos 6.0
Squid 3.1.10 (from base repository)
Log fragment:
---------------------------------------------------------------------
1347861663.915 9 192.168.1.48 TCP_DENIED/407 4209 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861663.929 0 192.168.1.48 TCP_DENIED/407 3985 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861663.953 1 192.168.1.48 TCP_DENIED/407 4170 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861663.973 4 192.168.1.48 TCP_DENIED/407 4213 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861663.986 0 192.168.1.48 TCP_DENIED/407 3985 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.008 1 192.168.1.48 TCP_DENIED/407 4170 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.026 3 192.168.1.48 TCP_DENIED/407 4209 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.040 0 192.168.1.48 TCP_DENIED/407 3985 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.065 1 192.168.1.48 TCP_DENIED/407 4170 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.084 4 192.168.1.48 TCP_DENIED/407 4209 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.097 0 192.168.1.48 TCP_DENIED/407 3985 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
1347861664.119 1 192.168.1.48 TCP_DENIED/407 4170 GET
http://feeds.store.ovi.com/service/bannerrequest.ashx? - NONE/- text/html
---------------------------------------------------------------------
Thank you very much,
Regards
