Thanks for the responses. I did some digging around and this is what I found. While running by disabling threads (-t) freeradius uses around 5MB while the normal mode uses about 43MB. In normal mode, freeradius seems to use a min of 9 threads even if I use extremely conservative server settings like start_servers = 1 max_servers = 1 min_spare_servers = 0 max_spare_servers = 0 Also, I noticed that in normal mode, a large anonymous section of memory (about 38M) is allocated. cat /proc/25923/maps (full output given below) b4720000-b6b69000 rw-p 00000000 00:00 0 while in -t mode, this section is very small (< 1M) cat /proc/17492/maps b6ac7000-b6ae6000 rw-p 00000000 00:00 0 Any thoughts/pointers to figure out where this large memory is allocated would be helpful. Disable threads (-t) ================ cat /proc/<pid>/status VmPeak: 5644 kB VmSize: 5644 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 3744 kB VmRSS: 3744 kB VmData: 508 kB VmStk: 132 kB VmExe: 416 kB VmLib: 4412 kB VmPTE: 12 kB VmPMD: 0 kB VmSwap: 0 kB Threads: 1 cat /proc/17492/maps 00481000-004e9000 r-xp 00000000 00:02 1530 /usr/sbin/radiusd 004f8000-004fa000 r--p 00067000 00:02 1530 /usr/sbin/radiusd 004fa000-004fc000 rw-p 00069000 00:02 1530 /usr/sbin/radiusd 004fc000-004fd000 rw-p 00000000 00:00 0 01bc1000-01c12000 rw-p 00000000 00:00 0 [heap] 01c12000-01c19000 rw-p 00000000 00:00 0 [heap] b6ac7000-b6ae6000 rw-p 00000000 00:00 0 b6ae6000-b6b06000 r-xp 00000000 00:02 1306 /usr/lib/libz.so.1.2.13 b6b06000-b6b07000 r--p 00010000 00:02 1306 /usr/lib/libz.so.1.2.13 b6b07000-b6b08000 rw-p 00011000 00:02 1306 /usr/lib/libz.so.1.2.13 b6b08000-b6b4b000 r-xp 00000000 00:02 1287 /usr/lib/libpcap.so.1.10.0 b6b4b000-b6b4c000 r--p 00033000 00:02 1287 /usr/lib/libpcap.so.1.10.0 b6b4c000-b6b4d000 rw-p 00034000 00:02 1287 /usr/lib/libpcap.so.1.10.0 b6b4d000-b6b61000 r-xp 00000000 00:02 735 /lib/libcap.so.2.32 b6b61000-b6b62000 r--p 00004000 00:02 735 /lib/libcap.so.2.32 b6b62000-b6b63000 rw-p 00005000 00:02 735 /lib/libcap.so.2.32 b6b63000-b6bc9000 r-xp 00000000 00:02 1295 /usr/lib/libpcre.so.1.2.12 b6bc9000-b6bca000 r--p 00056000 00:02 1295 /usr/lib/libpcre.so.1.2.12 b6bca000-b6bcb000 rw-p 00057000 00:02 1295 /usr/lib/libpcre.so.1.2.12 b6bcb000-b6bdd000 r-xp 00000000 00:02 1216 /usr/lib/libatomic.so.1.2.0 b6bdd000-b6bde000 r--p 00002000 00:02 1216 /usr/lib/libatomic.so.1.2.0 b6bde000-b6bdf000 rw-p 00003000 00:02 1216 /usr/lib/libatomic.so.1.2.0 b6bdf000-b6be0000 rw-p 00000000 00:00 0 b6be0000-b6c4c000 r-xp 00000000 00:02 1301 /usr/lib/libssl.so.1.1 b6c4c000-b6c50000 r--p 0005c000 00:02 1301 /usr/lib/libssl.so.1.1 b6c50000-b6c52000 rw-p 00060000 00:02 1301 /usr/lib/libssl.so.1.1 b6c52000-b6e29000 r-xp 00000000 00:02 1219 /usr/lib/libcrypto.so.1.1 b6e29000-b6e3a000 r--p 001c7000 00:02 1219 /usr/lib/libcrypto.so.1.1 b6e3a000-b6e3b000 rw-p 001d8000 00:02 1219 /usr/lib/libcrypto.so.1.1 b6e3b000-b6e3d000 rw-p 00000000 00:00 0 b6e3d000-b6e80000 r-xp 00000000 00:02 1234 /usr/lib/libfreeradius-radius.so.0.0.0 b6e80000-b6e81000 r--p 00033000 00:02 1234 /usr/lib/libfreeradius-radius.so.0.0.0 b6e81000-b6e82000 rw-p 00034000 00:02 1234 /usr/lib/libfreeradius-radius.so.0.0.0 b6e82000-b6ebc000 r-xp 00000000 00:02 1236 /usr/lib/libfreeradius-server.so.0.0.0 b6ebc000-b6ebd000 r--p 0002a000 00:02 1236 /usr/lib/libfreeradius-server.so.0.0.0 b6ebd000-b6ebe000 rw-p 0002b000 00:02 1236 /usr/lib/libfreeradius-server.so.0.0.0 b6ebe000-b6f5e000 r-xp 00000000 00:02 1220 /usr/lib/libc.so b6f6d000-b6f6f000 rw-p 0009f000 00:02 1220 /usr/lib/libc.so b6f6f000-b6f71000 rw-p 00000000 00:00 0 beb18000-beb39000 rw-p 00000000 00:00 0 [stack] bed9f000-beda0000 r-xp 00000000 00:00 0 [sigpage] beda0000-beda1000 r--p 00000000 00:00 0 [vvar] beda1000-beda2000 r-xp 00000000 00:00 0 [vdso] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] Normal mode =========== VmPeak: 43668 kB VmSize: 43668 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 38564 kB VmRSS: 38564 kB VmData: 38532 kB VmStk: 132 kB VmExe: 416 kB VmLib: 4412 kB VmPTE: 50 kB VmPMD: 0 kB VmSwap: 0 kB Threads: 9 cat /proc/7348/maps 004e9000-00551000 r-xp 00000000 00:02 1530 /usr/sbin/radiusd 00560000-00562000 r--p 00067000 00:02 1530 /usr/sbin/radiusd 00562000-00564000 rw-p 00069000 00:02 1530 /usr/sbin/radiusd 00564000-00565000 rw-p 00000000 00:00 0 0058b000-005dc000 rw-p 00000000 00:00 0 [heap] 005dc000-005e3000 rw-p 00000000 00:00 0 [heap] b453b000-b453d000 ---p 00000000 00:00 0 b453d000-b455e000 rw-p 00000000 00:00 0 b455e000-b4560000 ---p 00000000 00:00 0 b4560000-b4581000 rw-p 00000000 00:00 0 b4581000-b4583000 ---p 00000000 00:00 0 b4583000-b45a4000 rw-p 00000000 00:00 0 b45a4000-b45a6000 ---p 00000000 00:00 0 b45a6000-b45c7000 rw-p 00000000 00:00 0 b45c7000-b45c9000 ---p 00000000 00:00 0 b45c9000-b45ea000 rw-p 00000000 00:00 0 b45ea000-b45ec000 ---p 00000000 00:00 0 b45ec000-b460d000 rw-p 00000000 00:00 0 b460d000-b460f000 ---p 00000000 00:00 0 b460f000-b4630000 rw-p 00000000 00:00 0 b4630000-b4632000 ---p 00000000 00:00 0 b4632000-b6a7b000 rw-p 00000000 00:00 0 b6a7b000-b6a9b000 r-xp 00000000 00:02 1306 /usr/lib/libz.so.1.2.13 b6a9b000-b6a9c000 r--p 00010000 00:02 1306 /usr/lib/libz.so.1.2.13 b6a9c000-b6a9d000 rw-p 00011000 00:02 1306 /usr/lib/libz.so.1.2.13 b6a9d000-b6ae0000 r-xp 00000000 00:02 1287 /usr/lib/libpcap.so.1.10.0 b6ae0000-b6ae1000 r--p 00033000 00:02 1287 /usr/lib/libpcap.so.1.10.0 b6ae1000-b6ae2000 rw-p 00034000 00:02 1287 /usr/lib/libpcap.so.1.10.0 b6ae2000-b6af6000 r-xp 00000000 00:02 735 /lib/libcap.so.2.32 b6af6000-b6af7000 r--p 00004000 00:02 735 /lib/libcap.so.2.32 b6af7000-b6af8000 rw-p 00005000 00:02 735 /lib/libcap.so.2.32 b6af8000-b6b5e000 r-xp 00000000 00:02 1295 /usr/lib/libpcre.so.1.2.12 b6b5e000-b6b5f000 r--p 00056000 00:02 1295 /usr/lib/libpcre.so.1.2.12 b6b5f000-b6b60000 rw-p 00057000 00:02 1295 /usr/lib/libpcre.so.1.2.12 b6b60000-b6b72000 r-xp 00000000 00:02 1216 /usr/lib/libatomic.so.1.2.0 b6b72000-b6b73000 r--p 00002000 00:02 1216 /usr/lib/libatomic.so.1.2.0 b6b73000-b6b74000 rw-p 00003000 00:02 1216 /usr/lib/libatomic.so.1.2.0 b6b74000-b6b75000 rw-p 00000000 00:00 0 b6b75000-b6be1000 r-xp 00000000 00:02 1301 /usr/lib/libssl.so.1.1 b6be1000-b6be5000 r--p 0005c000 00:02 1301 /usr/lib/libssl.so.1.1 b6be5000-b6be7000 rw-p 00060000 00:02 1301 /usr/lib/libssl.so.1.1 b6be7000-b6dbe000 r-xp 00000000 00:02 1219 /usr/lib/libcrypto.so.1.1 b6dbe000-b6dcf000 r--p 001c7000 00:02 1219 /usr/lib/libcrypto.so.1.1 b6dcf000-b6dd0000 rw-p 001d8000 00:02 1219 /usr/lib/libcrypto.so.1.1 b6dd0000-b6dd2000 rw-p 00000000 00:00 0 b6dd2000-b6e15000 r-xp 00000000 00:02 1234 /usr/lib/libfreeradius-radius.so.0.0.0 b6e15000-b6e16000 r--p 00033000 00:02 1234 /usr/lib/libfreeradius-radius.so.0.0.0 b6e16000-b6e17000 rw-p 00034000 00:02 1234 /usr/lib/libfreeradius-radius.so.0.0.0 b6e17000-b6e51000 r-xp 00000000 00:02 1236 /usr/lib/libfreeradius-server.so.0.0.0 b6e51000-b6e52000 r--p 0002a000 00:02 1236 /usr/lib/libfreeradius-server.so.0.0.0 b6e52000-b6e53000 rw-p 0002b000 00:02 1236 /usr/lib/libfreeradius-server.so.0.0.0 b6e53000-b6ef3000 r-xp 00000000 00:02 1220 /usr/lib/libc.so b6f02000-b6f04000 rw-p 0009f000 00:02 1220 /usr/lib/libc.so b6f04000-b6f06000 rw-p 00000000 00:00 0 beb61000-beb82000 rw-p 00000000 00:00 0 [stack] befb8000-befb9000 r-xp 00000000 00:00 0 [sigpage] befb9000-befba000 r--p 00000000 00:00 0 [vvar] befba000-befbb000 r-xp 00000000 00:00 0 [vdso] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] ________________________________ From: Arran Cudbard-Bell <a.cudbardb@freeradius.org> Sent: Wednesday, May 22, 2024 5:33 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Peter Thomas (pethoma2) <pethoma2@cisco.com> Subject: Re: Tuning freeradius memory usage for small footprint machines

On May 22, 2024, at 18:34, Alan DeKok <aland@deployingradius.com> wrote:

On May 22, 2024, at 6:23 PM, Peter Thomas (pethoma2) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

...

I'm working on setting up FreeRADIUS on some pretty small servers with limited memory. I was wondering if anyone here has tips or tricks for reducing the memory footprint of FreeRADIUS. Are there any config tweaks to lower memory usage? I am running version 3.2.3 and the servers have about 256MB of RAM.

Compared to things like browsers, FreeRADIUS use zero memory.

The main way to lower memory is to disable all modules which aren't being used. After that, all of the memory is being used for the functionality you need.

--without-openssl would probably help too, otherwise, yes, most of the optional memory usage is in the modules, which are only loaded when they're explicitly enabled. -Arran

Thank you! Disabling atomic queues brought down the memory usage a lot to ~10M. Wonder why atomic queues take up so much additional memory (~30M)? Reducing the max_queue_size doesn't seem to help either. #ifdef HAVE_STDATOMIC_H thread_pool.queue[i] = fr_atomic_queue_alloc(autofree, thread_pool.max_queue_size); if (!thread_pool.queue[i]) { ERROR("FATAL: Failed to set up request fifo"); return -1; } #else ________________________________ From: Alan DeKok <aland@deployingradius.com> Sent: Monday, May 27, 2024 7:49 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Peter Thomas (pethoma2) <pethoma2@cisco.com> Subject: Re: Tuning freeradius memory usage for small footprint machines On May 24, 2024, at 9:46 PM, Peter Thomas (pethoma2) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Thanks for the responses. I did some digging around and this is what I found.

While running by disabling threads (-t) freeradius uses around 5MB while the normal mode uses about 43MB. In normal mode, freeradius seems to use a min of 9 threads even if I use extremely conservative server settings like start_servers = 1 max_servers = 1 min_spare_servers = 0 max_spare_servers = 0

The large memory block is due to the atomic queues. You can disable that by editing src/main/threads.c: ... // add the next line #undef HAVE_STDATOMIC_H #ifdef HAVE_STDATOMIC_H #include <freeradius-devel/atomic_queue.h> #endif ... That should lower memory usage. As for starting 9 threads, nope. That might be an OS / libc thing. FreeRADIUS only starts the number of threads you tell it to. Alan DeKok.