Search squid archive

Re: Squid, Kerberos and FireFox (Was: Re: leaking memory in squid 3.4.8 and 3.4.7.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux