FreeRADIUS can't make progress under certain load

[rihad]

On 09/10/2011 10:29 PM, Alan T DeKok wrote:
> rihad wrote:
>> Don't you think 5 second delay is pretty unusual for a LAN.
>    You misunderstand.
>
>    The packets are reaching the server just fine.  You've configured the
> server to do *something* strange.  So it's taking more than 20 seconds
> to respond.
>
>    This does not happen in the default configuration.
>
>> Yes, UDP
>> acct packets sometimes get dropped and never reach the server, but the
>> delay... It's much safer to sometimes drop 2 auth requests in a row for
>> the reason you stated than allow the server to reach a point where it's
>> unable to make further progress doing _current_ work.
>    *You* are the one who allowed the server to reach a point where it
> can't make progress.
>
>    The server *is* dropping the authentication requests.  See the log
> output you posted.
The current ones, yes, but alas not the new ones. We only get the 
"conflicting packets" messages when the system is under load, like when 
a "heavy" NAS reboots.
The code fix seems easy though.

>    I suggest understanding how RADIUS works before offering advice.
>
>> That's hundreds if not thousands (if you count acct packets too) of
>> requests all reaching the server nearly at the same time.
>    The server can handle 1000's and even 10's of 1000's of packets per
> second.  If you are seeing performance less than that, it's because
> you've configured something to be slow.
>
>    i.e. you're putting the accounting packets into a slow DB, or a DB
> without indexes.
>
>    When you make FreeRADIUS depend on something else like a slow DB, then
> the server performance is limited by that DB.
>
>    Blaming FreeRADIUS isn not appropriate.
>
>    Alan DeKok.
>
I'm not blaming anyone. Thanks for the great software and for sharing it 
with us. The great thing about open source is that I can tweak it to my 
needs. I'm not saying this is the best way to get rid of the problem. 
But it may be the easiest and the quickest.