Accounting drop when authentication

[Alan DeKok]

On May 3, 2025, at 7:51 AM, Ibrahemoo Ghost <ibrahemooghost at gmail.com> wrote:
> I recently had a strange problem, every time the system hits 150 auth
> requests per second accounting packets drop from 1000 req/s to about 200
> req/s and the system begins to delay accounting requests and accounting no
> response log messages arise in connected clients.

  The server has an internal queue which prioritizes Access-Requests over Accounting-Requests.

  This means that if there are many Access-Requests, and they take a long time to process, the Accounting-Request packets will be delayed.  The server will process Accounting-Requests only when there are no more Access-Requests to process.

  That could be the issue here. So is the server taking a long time to process Access-Requests?  You should be able to look at the server stats to see how long each packet is taking.  See sites-available/status, and sites-available/control.

  The "status" virtual server a return statistics in a RADIUS packet.

  The "control" virtual server lets you run a command-line "radmin" tool.  That lets you look at elapsed times (i.e. time between request and reply).  You can look at stats by home server, packet type, and listener.  Unfortunately, the elapsed times are only available via radmin, and not via RADIUS packets.  That makes it a bit more difficult to track the times automatically, but not impossible.

> The system operates normally under heavy load and no stress is visible to
> me in the sql server. I am using a monitor system and it shows no drop or
> increase in sql load.

  150 auth/s and 1000 acct/s should not be a heavy load.  We've tested the server at 20K auth/s using OpenLDAP, and 2K+ acct/s to SQL.

  The overall design of the configuration has more impact on performance than CPU.  i.e. Using a 36 core CPU won't help, if the server is spending all of its time waiting for the SQL server to return results.

  You can check this by creating a test configuration where the server does nothing at all, and immediately returns for all packets:

authorize {
	accept
}

accounting {
	ok
}

  This should be able to handle 20K+ packets/s.

> I have already checked and tuned mysql server to best values and checked
> the indices for the tables and everything is pretty well configured I am
> 80% sure the problem is with freeradius configuration because what solve
> the problem temporarily is restarting freeradius service until it
> rehits 150 auth req/s and problem rearise.

  That is weird.

> Do you agree with me that the problem is from freeradius or it could be
> something else and what can I do to solve it ?

  The problem is likely a combination of the server configuration and interaction with the databases.

  Some additional things to check:

* don't send logs to systemd for syslog.  We've seen it max out at a few hundred log messages per second, which blocks FreeRADIUS

* remove everything from the configuration that you're not using.  The "unix" module is very slow, for example.  If you don't need it, remove it from the configuration

* use radmin to get the full server stats, including elapsed time for requests, and how long packets are staying in the input queues.

  Probably the most important thing to do is the last one.  Looking only at overall packets/s is just too "high level" to tell you much about what the server is doing.  Once you get detailed stats abut everything the server does, it becomes much easier to tell exactly where the problem is.

  Alan DeKok.