Accounting-Response taking too long

mustafa mujahid mustafa.mujahid at outlook.com
Thu Mar 8 08:49:53 CET 2018


My apologies Alan,

The server has absolutely nothing extra aside from the default configuration, no scripts or any type of automation at that. Its a completely default configuration. I have investigated the DB and plotted a latency graph with the help of the wire shark output. The graph is attached. I first thought it was the DB that was responding slowly but the graph shows only a few requests taking longer than 1 second to complete (y-axis is seconds). Now the issue occurs during the load time of 8pm, I would love to paste the debug output but the debug moves so fast that nothing can be tracked. I'm quite stuck and this has become an issue for us. Anything at all that could be recommended that I can check to identify the issue would be greatly appreciated.  Network latency from NAS to Radius and Radius to DB is less than 1 ms. Thank you as always!

BR/Mustafa

On 06/03/2018 12:21 AM, Alan DeKok wrote:

On Mar 5, 2018, at 2:12 PM, mustafa mujahid <mustafa.mujahid at outlook.com><mailto:mustafa.mujahid at outlook.com> wrote:


Radius version : 2.2 (old, but reliable)


  You should upgrade to 2.2.10.



Ive recently ran into a problem with our accounting Radius server which have seen smooth sailing for a long time. Basically every night at 8pm a stop request is generated for all users and then consequently a start to change the package assigned to the customer. Currently our Radius is serving 19000 customers. The problem we are facing is that the NAS which is basically a session and resource controller sends the accounting-requests but the accounting-responses are taking from around 7 to 10 seconds from the time the Acct-requests come in to be dispatched to the NAS as observed from wire shark, please see attachment.


  The default configuration works, and doesn't take 10s to respond.  So it must be something on your local system which is causing the problem.



The same is reflected in the radius accounting logs. The problem that occurs due to this is that the NAS when it doesn't receive the response in the given time keeps retrying, sending accounting-requests again and again and eventually errors with retries expired and fails.


  That's what the NAS should do.



Should I increase the ''max_requests'' in radiusd.conf, currently it set to 2048. The comments say it should be 256 multiplied by the number clients. Now by clients does it mean the actual number of customers in my case or the number of NASs that connect to the Radius server. (Apologies for the lack of understanding)


  The NASes.  But changing that number won't help.



Accounting responses usually take milliseconds but I don't know why it's taking so long in this case. If I could be guided in how to troubleshoot this or any assistance in this regard would be greatly appreciated.


  See this:  https://wiki.freeradius.org/list-help

  You haven't said what you've configured FreeRADIUS to *do* with accounting packets, so it's difficult to help you.  All we can say is that there is no magic "wait 10s" setting in the server.

  In general, delays are due to local issues.  e.g. slow database, slow script your executing, etc.

  But you should ask a *good* question to get a good answer.  Right now, vague questions get vague answers, which aren't overly helpful.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: db latency.PNG
Type: image/png
Size: 271315 bytes
Desc: db latency.PNG
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20180308/ce4955d4/attachment-0001.png>


More information about the Freeradius-Users mailing list