recommendations for max_servers
Alan DeKok
aland at deployingradius.com
Wed Sep 24 20:34:04 CEST 2014
Louis Munro wrote:
> I actually wrote a wrapper (in C) around ntlm_auth to log the times
> between calling ntlm_auth and it returning a value.
> This is where I found values that vary wildly between 7ms and <= 3000ms
That's a problem. If the user lookup is taking 3 seconds, of COURSE
FreeRADIUS will fall over.
Try attacking a 10,000 pound weight to your car, and see how fast it
goes. You wouldn't blame the car for not being able to move, right?
> I see most threads just doing a sem_wait while Thread 1 is doing all the
> work.
Most of the threads will be waiting for ntlm_auth to return. Thread 1
will be handling all of the network IO, and doing real work.
> This would be easier of course if I had consistently bad performance.
> As it is, things only fall apart when a significant load is reached.
That's ALWAYS what happens when a system is overloaded. The system
falls over. That's what "overload" means.
> There, I just got another flurry of these while replying:
> Info: Child PID 26929 (/usr/bin/ntlm_auth) is taking too much time:
> forcing failure and killing child.
Yes. Your ntlm_auth process is taking too long, and is destroying
FreeRADIUS. I can't be any clearer about that.
No amount of poking FreeRADIUS will make ntlm_auth run faster. And
making ntlm_auth run faster is the ONLY solution to the problem.
I've said it before, and I'll say it again. Using Active Directory is
a terrible decision for almost everyone. It's slow, awkward, unstable, etc.
FreeRADIUS can do 50K+ authentications per second from the "users"
file. So there is no way the problem is caused by FreeRADIUS.
Alan DeKok.
More information about the Freeradius-Users
mailing list