Re: [squid-users] FATAL: Too many queued negotiateauthenticator requests

First thing I would recommend in your configuration, is _INCREASE_ the amount of kerberos children, being your primary authenticator. 10 is a very lowball number for 400 users, I would recommend around 25-30, and set the NTLM auth children to around 10-15 for each. My proxies serve around that same number for each server, around 300-375 on avg.

---------------------------------------------
Chad E. Naugle
Tech Support II, x. 7981
Travel Impressions, Ltd.
 

>>> Nick Cairncross <Nick.Cairncross_at_condenast.co.uk> 9/28/2010 10:28 AM >>>
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

Travel Impressions made the following annotations
-------------------------------------------------------------
"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments.
Thank you."
Received on Tue Sep 28 2010 - 14:45:50 MDT