accounting packet loss
lirankessel at gmail.com
Tue Sep 27 19:59:15 CEST 2016
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 .
> 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?
> 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
More information about the Freeradius-Users