I had this kind of 100% CPU problem with auth helpers when upgrading to squid 3.4. I use negotiate_wrapper, kerberos, ntlm and basic auth. Then I had to fall back to 3.3 and it is production until now, with some troubles with broken clients, but with normal cpu usage most of the time. Can you try with squid 3.3 and see if that version don't have the same problem? On Thu, Oct 23, 2014 at 8:41 AM, Victor Sudakov <sudakov@xxxxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Amos Jeffries wrote: >> >>>>> And about the basic issues that you were having with >> >>>>> performance, does it help to run Kerberos instead of NTLM >> >>>>> (it should...)? >> >>>> >> >>>> I have even moved squid to a new virtual machine (FreeBSD >> >>>> 9.3-RELEASE under VMWare, 1 GB RAM) and performance still >> >>>> sucks royally. >> > >> > I don't know what's happening with squid but this kind of CPU >> > consumption is just not normal: >> >> Well, it both is and it isn't. >> >> Squid *will* use the CPU hardware right up too the 100% limit if it >> has any need to that is normal. >> >> Needing to for long periods of time is not particularly normal ... >> except under conditions where the traffic load is too high for the >> server hardware to cope with. >> >> I did see a scenario with behaviour exactly like this at a client some >> time back. After detailed analysis it turned out that their NTLM >> helper had been so slow that clients traffic spent more time waiting >> for next auth action than processing requests. > > Looks like my scenario but I am already using a Kerberos helper. > > I'll increase the number of virtual CPUs tonight. The OS kernel should > parallel the authentication children for 2 CPUs, maybe that will make > a difference. > >> But when they moved to the higher performance Kerberos and a simpler >> proxy configuration the client traffic throughput increased to a >> req/sec rate faster than the server could cope (3x previous rate). >> It thus was bottlenecked by 100% CPU speed limit rather than by NTLM >> delays. >> >> So, "normal" depends on what exactly is the cause of the behaviour. >> >> What req/sec traffic rates are you seeing on what you consider a >> "normal" / older proxy compared to this one? > > The number of clients and queries is exactly the same as with the > older proxy. Nothing has changed other than squid version. Besides, > the older proxy was using the LM auth helper. > >> >> Also, what are the heleprs stats looking like in the cachemgr report? > > Here it is: > > Sending HTTP request ... done. > HTTP/1.1 200 OK > Server: squid/3.4.8 > Mime-Version: 1.0 > Date: Thu, 23 Oct 2014 11:37:16 GMT > Content-Type: text/plain > Expires: Thu, 23 Oct 2014 11:37:16 GMT > Last-Modified: Thu, 23 Oct 2014 11:37:16 GMT > X-Cache: MISS from proxy.sibptus.transneft.ru > X-Cache-Lookup: MISS from proxy.sibptus.transneft.ru:3128 > Via: 1.1 proxy.sibptus.transneft.ru (squid/3.4.8) > Connection: close > > Negotiate Authenticator Statistics: > program: /usr/local/libexec/squid/negotiate_kerberos_auth > number active: 25 of 100 (0 shutting down) > requests sent: 51956 > replies received: 51956 > queue length: 0 > avg service time: 1 msec > > ID # FD PID # Requests # Replies Flags Time Offset Request > 0 9 9803 32120 32120 0.001 0 (none) > 0 11 9804 9412 9412 0.011 0 (none) > 0 13 9805 4477 4477 0.011 0 (none) > 0 15 9806 2338 2338 0.011 0 (none) > 0 17 9807 1320 1320 0.009 0 (none) > 0 380 9809 789 789 0.009 0 (none) > 0 393 9810 521 521 0.011 0 (none) > 0 396 9811 332 332 0.025 0 (none) > 0 398 9812 221 221 0.025 0 (none) > 0 400 9813 144 144 0.025 0 (none) > 0 402 9814 100 100 0.024 0 (none) > 0 404 9815 58 58 1.211 0 (none) > 0 406 9816 38 38 1.211 0 (none) > 0 408 9817 29 29 1.211 0 (none) > 0 410 9818 20 20 1.211 0 (none) > 0 577 9902 13 13 1.211 0 (none) > 0 587 9903 8 8 1.211 0 (none) > 0 651 9904 5 5 1.211 0 (none) > 0 668 9905 4 4 1.211 0 (none) > 0 673 9906 3 3 1.211 0 (none) > 0 677 9907 2 2 3.669 0 (none) > 0 679 9908 1 1 3.669 0 (none) > 0 681 9909 1 1 3.669 0 (none) > 0 684 9910 0 0 0.000 0 (none) > 0 688 9911 0 0 0.000 0 (none) > > Flags key: > > B = BUSY > C = CLOSING > R = RESERVED > S = SHUTDOWN PENDING > P = PLACEHOLDER > > > - -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:sudakov@xxxxxxxxxxxxxxxx > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUSOlbAAoJEA2k8lmbXsY0r7AIAJhEAcUYajdnLa+geOlMblaG > 8w+EyzWX6H+Sg1qaevBi28rB16qo0aAez4SY+GvTtle3qUnGdU3xpMxOKz+F4LV9 > 8Rz47bV4XfTyB8o4YF7ukFE9u/1CGQP+wk9FKGWZwpANiaE633PyMnEG0ftJYo1i > dK96bCBMhNjArbwqKGgR1SQgO7KfJhVYspLs8700d/sgV2d8xx7FXoxICLhyG6Xz > N+yUETFn6el6CUFnM+YGKBXylfzp56KQg92pP/TNYZ9cj7vH4vKDsexmq3VrACTn > FsF7cz3vQWMaBrsTSLExFzcSm2Gri5WewjeMR9HBzxNBCw24VvbSn0CL7e5sbRw= > =0Hh1 > -----END PGP SIGNATURE----- > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
