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