For me, the version 3.4.3 have the same behavior. It uses 100% CPU (in one core, the others are normal). For the users, it's just a slowed down navigation. As soon as I change back to the 3.3.8, everything works fine.
Actually I'm not sure the problem is caused by ntlm or kerberos or external_acl_type or anything related to authentication. But I can't disable it to be sure. This time I will leave one server runnnig with 3.4.3 and try to debug. I have already tried to increase the debug level on every auth helper, but I couldn't see nothing wrong. I'll try debug_options ALL,9 tomorrow. With strace, should I look for something? System calls squid does all the time... On Sun, Jan 26, 2014 at 11:47 PM, Alan <lameventa...@gmail.com> wrote: > On Wed, Jan 8, 2014 at 1:05 PM, Amos Jeffries <squ...@treenet.co.nz> wrote: >> On 7/01/2014 10:21 p.m., Rietzler, Markus (RZF, SG 324 / >> <RIETZLER_SOFTWARE>) wrote: >>> thanxs, >>> >>> our assumption is, that it is related to helper management. with 3.4. there >>> is a "new helper protocol", right? >> >> Right. That is the big user-visible bit in 3.4. >> >> But there are other background changes involving TCP connection >> management, authentication management, ACL behaviours and some things in >> 3.3 series also potentially affecting NTLM. >> >> The feature changes just give us a direction to look in. We still have >> to diagnose each new bug in detail to be sure. There are others already >> using NTLM in older 3.3/3.4 versions without seing this problem for example. >> >>> our environment worked with 3.2 without problems. now with the jump to 3.4. >>> it will not work anymore. so number of requests are somehow important but >>> as it worked in the past... >>> >>> if we go without ntlm_auth we can't see any high cpu load. so the first >>> thought ACL and eg. regex problems can be >>> discarded. maybe there are some cross influences. but we think it lies >>> somewhere in helpers/auth. >> >> Did you get any better cache.log trace with the debug_options 29,9 84,9? >> >> Amos >> > > I have the same problem here, I noticed it when I went from 3.3.8 to 3.4.2. > I assumed the problem was introduced with 3.4.x, so I went back to > 3.3.11 and it is working fine. > I'm using aufs, negotiate_kerberos_auth and a custom external acl helper. > > Unfortunately these are production servers, so I can't strace or > increase logging as suggested.