On Sep 29, 2022, at 9:32 AM, Imdad Hasan <imdadalikadiwala0@gmail.com> wrote:
Right now in current version of my app,
1.) For accounting i am using pre-compiled FreeRADIUS queries with two tables approach one radacct for live and another for closed sessions.
That's good.
2.) In update control i am updating in/out octets on another table for specific user total usage. (Also for Accounting)
OK. How fast are those queries? How big are the tables? Do the tables have appropriate indexes?
3.) For Authentication/Authorization i am still using exec with php script, i am planning to move on perl, but still confuse because of some old posts about perl module.
The Perl module is well documented and it works. While Perl is slow, it will be much faster than exec+PHP.
- MySQL server have 32GB RAM and 8-Core CPU with Mysql READ-COMMITED isolation mode. - MySQL server CPU usage is max to max 10% to 15% On high load.
- FreeRADIUS server have 4GB RAM and 2-Core CPU. - FreeRADIUS server CPU usage is around 50 to 75%. but the half of total usage (around 30%) is by the system kernel itself. mostly these two function of the kernel.
The kernel shouldn't be using that much CPU time. Something odd is going on. Perhaps the many exec scripts you're running.
- MySQL and FreeRADIUS is linked in the local network in one VPC of Amazon AWS.
- The average load of internet subscriber is around 35k. and i set 5mins interim update time for every subscriber for accounting.
So about 60 packets/s on average. This should never be a problem for FreeRADIUS.
- most of time is working fine, but some times it's gives below errors and hangs.. on client sides it's showing *radius time out.*
Don't debug server issues by looking at the client logs.
*Thu Sep 29 07:40:54 2022 : WARNING: (4098875) WARNING: Module rlm_sql became unblocked*
*Thu Sep 29 07:40:54 2022 : Error: Received conflicting packet from client omnet port 54191 - ID: 82 due to unfinished request in module sql. Giving up on old request.*
Your SQL database is slow. Fix it. * clean up old / unused rows * make sure the tables have appropriate indexes * delete unused indexes * make sure all queries have indexes * make sure any custom queries don't result in full table scans. This isn't a FreeRADIUS issue. No amount of poking FreeRADIUS will make your database faster. (Other than using more efficient queries). The default schema / indexes / queries work. They're fine for thousands of packets per second. Something you've done locally is making the database slow. Alan DeKok.