accounting packet loss

[Alan DeKok]

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.