On 20/06/14 14:28, Eliezer Croitoru wrote:
OK after reading the config file it seems like there are couple things
that we\you should be aware of when looking at the issue:
1. External helpers code was changed from 3.3 to 3.4 (one way)
2. you are using delay_pools.
3. you are using ntlm authentication.
In the past there was suspect which said that the new helpers related
code might cause an issue like that but yet to be verified.
(this needs testing and idea on how to show and proof that this is
either a real suspect or a bogus one)
About ntlm auth.. There is sure some overhead related to using ntlm
and cpu usage due to couple layers one on top of the other and it was
proofed that there is a difference between using ntlm and not using
ntlm at all.
It dosn't proof what in ntlm is causing the issue and I am not sure it
will be fixed due to the basic fact that ntlm maintenance stopped at
200X 3 or 6 and which I am not sure about the accurate date yet.
The only options I see is doing two things:
Remove the ntlm and group external helpers related acls for a testing
period to verify that only when these works\runs the high cpu usage is
there and while the delay_pools are still intact the system runs fine.
This will narrow down the issues from 3 to 2 "ideal" suspects.
There is also another suspect which is over-usage of squid ACLs to
block or allow domains\regex\etc but it can be verified that these are
not an issue by removing the external_acl and ntlm helpers and test
how squid behave.
** Another tiny detail would be: what bandwidth is this server
pushing? How many MBps or Mbps(MBps = mbps/8)?
I know that it can be painful to run these tests but if you have the
option to verify the issue it will narrow the issue down pretty fast.
Also I am almost sure that this thread should be summarized into
either a bug report or first a thread in squid-dev list so you would
get better help and directions from the developers.
Thanks,
Eliezer
Hi,
The first thing I'm going to try is disabling delay pools for CONNECT,
then after that for all requests.
As disabling NTLM will leave us more open than I'd like that would be
the following step.
Cheers
Alex
