Observing a common error in Freeradius with Postgres but not justification why it happens

[Nathan Ward]

On 2/09/2023 at 9:10:10 PM, Ibrahim Al Mahfooz <ibrahim.nezar at sevennet.net>
wrote:

> Hello all,
>
> <stuff>
>
> The questions to summarize are :
> 1. Is ~900 TPS and 10ms acceptable DB performance for accounting?
>

Depends what your queries are and your table sizes and so on - you say you
have modified them but have not provided the changes or the logs or any
postgres table metrics so no way to tell.
It will also depend heavily on the storage - postgres by default does not
complete a commit until the data is written to disk. If you have SSD vs.
spinning rust it will be very different.

I don’t think your pgbench data is very useful, it is using a different
number of clients, and it is doing completely different queries to
FreeRADIUS on completely different schema.
Pgbench is useful for comparing 2 systems, it is not useful for evaluating
one system in isolation.

2. In the max_requests setting, what does the clients mean here, does it
> mean NAS client or SQL connections based on max requests? how to size it?
>

The documentation describes what this parameter is where you configure it,
and says: "This should be 256 multiplied by the number of clients. e.g.
With 4 clients, this number should be 1024."

https://github.com/FreeRADIUS/freeradius-server/blob/db3d1924d9a2e8d37c43872932621f69cfdbb099/raddb/radiusd.conf.in#L224

3. What could be the culprit given the fact all the servers are relaxed?
>
> Really appreciate your guidance here
>

This is almost certainly going to be a Postgres tuning problem rather than
a FreeRADIUS problem.

How big are your tables (rows and GB) and how big are your indexes (GB)?
Are you deleting old data from the tables and vacuuming them regularly? You
probably should be doing that, unless you know to how scale postgres
properly.

--
Nathan Ward