[EXTERNAL] Re: radiusd crashes. ASSERT FAILED src/main/threads.c[794]

[Winfield, Alister (Senior Solutions Architect)]

I’ll make a suggestion, do the SAME queries from the SAME server when there is the SAME load. Anything else is a waste of time when looking at DB performance. Add to this that it could be a wonderful list of issues here are my current favourites when faced with a slow RADIUS  (or in fact any high-packet-rate service).

Note that some of these only happen when operating at high enough packet rates.

Network packet loss,
Security tools,
Security features like anti-ddos,
Too small a network link 1G vs 10G vs 40G depending on size of issue
NIC card ring buffers too small
NIC settings bad for UDP services (especially interrupt and per-interrupt processing settings)
OS buffers too small (or too big) sadly this one depends on what you are looking at.
DNS is slow (especially the totally terrible performing proxies that are default for some ‘container’ setups)
TLS (needs random numbers is slow because its blocking on /dev/random)
Switch port has flooded per-port buffer
Firewall is running out of resource (CPU / MEMORY etc)
Load-balancer is running out of a resource.
DB is running with a socket limit that’s too small
DB is running with a process max-connections limit that’s too small
Some other process/VM/container is using too much I/O and thus destroying performance
Some other process/VM/container is using too much memory causing swapping
Not enough resources allocated (servers /cpu/memory/etc).
Missing Indexes
Crazy expensive query
Crazy expensive ‘insert or update’

I know its service diagnosis 101 but you can see not one of these is FreeRADIUS it’s surprisingly rare that it’s actually the FreeRADIUS code itself. So much so I’ll exhaust the external causes before looking too hard at what FreeRADIUS is doing.

A.

From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk at lists.freeradius.org> on behalf of Sergey Kodentsev <sergk at ic.vrn.ru>
Date: Friday, 23 May 2025 at 17:21
To: freeradius-users at lists.freeradius.org <freeradius-users at lists.freeradius.org>
Subject: [EXTERNAL] Re: radiusd crashes. ASSERT FAILED src/main/threads.c[794]
Hi,

23.05.2025 17:50, Alan DeKok via Freeradius-Users пишет:
>> You are checking high-level database stats, and doing test queries. They don't matter.
>>
>> I repeat, I do not make test queries.
>> I look at the execution time of real queries from a working freeradius using MariaDB.
>> And this response time differs significantly from what freeradius shows, although it should be the same.
Sergey Kodentsev
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<http://www.freeradius.org/list/users.html>
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing at sky.uk. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD