FreeRADIUS can't make progress under certain load

[rihad]

On 09/11/2011 06:31 PM, Arran Cudbard-Bell wrote:
>>> Also, if you think processing the accounting data might be slowing down authentication processing you might want to consider using a detail writer and detail reader virtual server (there are examples in sites-available, robust something or other). The server can spool accounting requests to a detail file very quickly, much quicker than rlm_perl could process them. The reader intelligently throttles based on server load, so unless the billing software needs to be notified in real time of a client connecting or disconnecting, it's a very good solution for dealing with load spikes.
>>>
>> Thank you, Arran, I think the problem was solved because new requests are no longer accepted when the system is under heavy load, so FreeRADIUS can sustain the load spikes until they're over.
>>
> Undoubtedly. What I was saying is that you might want to prioritise traffic during a spike so that processing authentications take precedence over processing billing data, so your customers get a more reliable service, and can reconnect quickly.
>
> But yeah, i'm done with this thread. Seems like you have something that works for you... and i'm open to ideas for documentation, but your use case is a-typicial, and honestly I think tuning the number of worker threads is a better way of achieving what you're doing.
>
> Anyway we won't be changing the documentation, and we won't be adding your modification to the server.
>
Just to note: I didn't touch the source, all I did was lower max_requests.
Did you mean something like decreasing max_servers (was: 50), and 
setting max_queue_size somewhere around 10?
Tweaking only max_servers never helped. I've had it as little as 5, and 
as big as 100.
> TTFN
>
> -Arran
>
> Arran Cudbard-Bell
> a.cudbardb at freeradius.org
>
> RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
>
>