Search squid archive

FATAL: Too many queued negotiateauthenticator requests

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

 



Hi,

I've *just* started to see the following error on my squid box and I need some assistance! It primarily serves Kerberos users and NTLM secondary: about 70/30. This comes after I've directed a new batch of users to use squid.

==
2010/09/28 14:53:34| storeDirWriteCleanLogs: Starting...
2010/09/28 14:53:34| WARNING: Closing open FD   69
2010/09/28 14:53:34|   Finished.  Wrote 0 entries.
2010/09/28 14:53:34|   Took 0.00 seconds (  0.00 entries/sec).
FATAL: Too many queued negotiateauthenticator requests
Squid Cache (Version 3.0.STABLE24): Terminated abnormally.
CPU Usage: 26.745 seconds = 9.560 user + 17.185 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
        total space in arena:   18800 KB
        Ordinary blocks:        18071 KB     84 blks
        Small blocks:               0 KB      0 blks
        Holding blocks:          8460 KB     35 blks
        Free Small blocks:          0 KB
        Free Ordinary blocks:     728 KB
        Total in use:           26531 KB 141%
        Total free:               728 KB 4%
==
My relevant conf:
http_port 172.16.10.197:8080
auth_param negotiate program /usr/lib/squid/squid_kerb_auth -r -i -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive on

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 40
auth_param ntlm keep_alive on

auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

cache_peer myupstreamproxy parent 8080 0 no-query proxy-only no-digest default

http_access allow AuthenticatedUsers
==

The proxy needs to be able to handle upto 400 users at a time, so this is little worrying.. I've done some digging and noticied some file descriptor things I should check - could any one help me there?
More likely than that is that the helpers are not able to process the requests resulting in a refusal at the browser.
I found something by Henrik (back in 2004!):

"So it could simply have been that you have more than 15 or so users
authenticating to the proxy at the same time.. NTLM is quite chatty and
uses the helpers a lot. It should be possible to make a formula based on
the number of concurrent users "numbers_of_helpers = X *
number_of_concurrent_users" but I do not have any useful data on what X
should be but I would guess around 0.5 or so should be safe..
number_of_concurrent_users is the peak number of users using the proxy
at the same time (within one minute)."

...and wondered if the calculation is at all valid for Kerberos users?

Help would be appreciated!
Thanks
Nick

The information contained in this e-mail is of a confidential nature and is intended only for the addressee.  If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful.  Disclosure to any party other than the addressee, whether inadvertent or otherwise, is not intended to waive privilege or confidentiality.  Internet communications are not secure and therefore Conde Nast does not accept legal responsibility for the contents of this message.  Any views or opinions expressed are those of the author.

The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover Square, London W1S 1JU



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

  Powered by Linux