accounting packet loss

[liran kessel]

The MySQL server isn’t going down, its just running high CPU aggregations and so it isnt’ able to handle the load of writing new events .
I agree that the problem is the MySQL but was hoping I could buffer events within freeRadius for a few seconds during these short windows in order to handle the load without needing to add hardware.

Thanks for the explanation.

> On 27 Sep 2016, at 6:26 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Sep 27, 2016, at 11:12 AM, liran kessel <lirankessel at gmail.com> wrote:
>> However after changes we have made to other processes that run on the MySQL we have reached the point that we are only loosing messages for 2 or 3 seconds every 15 minutes when our scheduled processing runs.
> 
>  Which is still terrible.
> 
>  If you want RADIUS to work well, then don't take the MySQL server down while the RADIUS server is running.
> 
>> What I want to do is try and configure the radius to have a large enough cache to be able to handle this short spikes without losing messages, as I don’t have shortage in RAM.
>> 
>> I have played around with the following parameters in the radiusd.conf file but they don’t see to be helping .
>> max_requests
>> max_request_time
>> cleanup_delay
> 
>  If you read the documentation for those configuration items, you'll see that they have nothing to do with SQL, or with caching requests.
> 
>> we are not sending a reply ack to the GGSN for any message so cleanup delay as I understand it isn’t critical.
> 
>  You're not sending accounting ACKs to the GGSN?  That's weird.
> 
>> is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages? 
> 
>  No.
> 
>  Fix your MySQL server so that it doesn't go down.  The best way to do this is to use MySQL replication.  Have a master + slave.  FreeRADIUS writes to the master.  The master replicates to the slave.  And the complex processing runs on the slave, not the master.
> 
>  No amount of poking FreeRADIUS will fix the problem.  You might be able to mask the problem for a while, but the problem will still exist.
> 
>  Alan DeKok.
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html