On 10/04/11 01:09, Eugene M. Zheganin wrote:
Hi.
On 15.03.2011 16:54, Amos Jeffries wrote:
Start with the -d option.
Then add/update debug() lines to any place that looks useful. I'm
interested in making the debug helpful so patches for that are welcome
upstream.
debug() operates identical to printf() but sends the result to the
helper channel for Squid cache.log.
FWIW, I think adding pam_strerror() results into both of the WARNING:
messages with that text should be enough to point at the actual problem.
Well... I did all of that (and it didn't help). By the way, debug seems
to be a macro, rather than a squid channel logging function (could it be
even possible ? main part of squid 3.x is written in C++ and the helper
part - in C). Anyway, may be it's time to describe my problem, rather
than to describe the solution as I see it. :)
Okay, the problem description: as I said I have a proxy. That's the
company main proxy, and the wpad for the network of more than 2K
machines points at it. So, during the weekdays I have loads of requests
from all sorts of clients, most of them remains blocked, but all of the
basic authentication requests are handled by pam_auth. I have 35
simultaneously running pam_auth processes. During load peaks I ususally
have 3-5 (sometimes even more) pam_auth processes that eat 100% of the
both CPUs all together. I used to think that those are the processes
that squid failed to release. But, when I kill some of it to release the
CPUs from unnecessary load, squid complains in its log like that:
WARNING: basicauthenticator #8 (FD 93) exited
It's obvious that I'm wrong and this isn't the helper squid cannot
release, but this is the actually running helper. So the questions are
- why only small parts of basic helpers are affected with such load ?
credentials tests are requested of the first available helper program.
Under load every time the first helper finished it gets a new request to
handle, so is constantly in use. So the first few will get all the load
and later ones will only get load when the earlier one(s) fill up.
- why such load even exists ? when I kill affected processes squid
continues to run without influencing its clients for some time. Then the
load appears again.
That is unclear. It could be anything from that being the actual request
load, to a config design problem causing unnecessary calls to the auth
helpers, to a problem in PAM dong a lot of extra work for nothing.
- and, of course, what can be done to solve this.
I had a look at the code of the helper - it seems to be very
straightforward and simple, so I don't see how such a simple code can
eat CPU.
If it is called too often it can east CPU, or if the PAM backend is the
actual CPU consumer.
The basic helper config is:
auth_param basic program /usr/local/libexec/squid/pam_auth
auth_param basic children 35
auth_param basic realm Squid[Kamtelecom]
auth_param basic credentialsttl 1 minute
60 seconds between checks with the PAM helper will raise load. On small
networks with few clients this is not a problem, but larger ones it
could be.
auth_param basic casesensitive off
and the pam config for the squid service name is:
auth sufficient pam_unix.so no_warn
auth sufficient /usr/local/lib/pam_winbind.so try_first_pass
auth sufficient pam_krb5.so no_warn try_first_pass
auth required pam_deny.so no_warn
I don't believe pam_winbind or pam_krb5 will work with this config using
Basic auth. They are for NTLM and Negotiate auth respectively.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.6
