FreeRADIUS can't make progress under certain load
rihad at mail.ru
Sun Sep 11 14:41:23 CEST 2011
On 09/11/2011 04:58 PM, Alan DeKok wrote:
> rihad wrote:
>> On 09/11/2011 01:58 PM, Alan DeKok wrote:
>>> Your Perl script is breaking the server. Fix it.
>> I know that. The auth& billing software we're using is admittedly slow.
> Then stop your complaints about FreeRADIUS. Don't change FreeRADIUS.
> It's fine.
>> But see how easy it was to lower max_requests and allow FreeRADIUS to
>> make progress on its own during load spikes (like when a NAS reboots).
> That is a bad solution, and one which makes the problem worse.
It's a working one. Just think of it: some of the new requests get
dropped because the server thinks it can't handle them right now: it has
already received max_requests req's during the past cleanup_delay seconds.
Doesn't my tweak do exactly this:
* FUTURE: Add checks for system load. If the system is
* busy, start dropping requests...
* We can probably keep some statistics ourselves... if
* there are more requests coming in than we can handle,
* start dropping some.
>> PPPoE clients (most of which are ADSL modems) retry auth anyway. Noting
>> in radiusd.conf that max_clients shouldn't be set higher than the system
>> can process within cleanup_delay seconds might save some poor soul their
>> spare time in the future.
> I doubt that. Everyone else ensures that their system can handle the
>> Let me just quote Mr. Arran again:
>>> Your NAS is also behaving very strangely. FreeRADIUS only gives up on
>>> processing a request if a request with a duplicate ID, SRC IP, and SRC
>>> PORT but a different REQUEST AUTHENTICATOR is received.
>>> When a NAS retransmits it should use the same ID, SRC IP, SRC PORT and
>>> REQUEST AUTHENTICATOR.
>> By this it should be clear that it's not NAS resending unanswered auth
>> requests, but rather ADSL modems issuing _new_ requests.
> That doesn't matter, even if it was true.
> Pretty much every piece of equipment you have is horribly broken.
> Your solution is to break FreeRADIUS rather than the fix the equipment.
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
More information about the Freeradius-Devel