On Sun, 10 Oct 2021, 12:16 Alan DeKok, <aland@deployingradius.com> wrote:
On Oct 9, 2021, at 10:28 PM, Nathan Ward <lists+freeradius@daork.net> wrote:
As well as the VRF issue, you can experience this in global context if the database connection is configured with a query timeout and the bulk session update does not complete in time.
It seems very odd to me that you would have an Accounting-On/Off query taking anywhere near what a DB query timeout is. That doesn’t sound like an MX issue - that sounds like some index tuning is required, or perhaps the query is doing a large amount of work that could be handled another way?
If it's a big GGSN, then updating 100K rows can take time. Doing that update in an asynchronous transaction would be better, perhaps.
Indeed. You can also maintain a per-NAS epoch table using Accounting On/Off. Then adjust routine queries to join against this (or just make a view in which acctstoptime = NULL is replaced with the end of the previous epoch unless the session started afterwards), allowing you to ignore sessions not belonging to the current epoch. But it's the kind of thing that only becomes with doing when needed because of the added schema/query complexity...