Is there a memory leak in the SMF?

While using free5gc-compose versions 3.4.3 and 4.0.0, the SMF experiences a significant amount of memory usage. I first encountered this while having issues with video transmission. To make it repeatable, I’ve been using the command ping <core-ip-address> -i <tun-interface> -A -s 2048. Monitoring the system resources with docker stats, we see:

Typically, the SMF sat at around 20% memory usage but was seen spiking up to 800%. What’s really concerning is the amount of memory being used and never given back to the system. On this machine, it had taken 117 GiB of memory before I shut off the testing.

This has been tested over the openairinterface5g gNB with openairinterface5g nrUE and the srsRAN gNB with srsRAN 5G UE. The SMF performs the same over both sets of software.

This SMF does not retain memory usage like this in free5gc-compose release 3.3.0.

The memory usage in the SMF does not seem to be causing issues with the video transmission itself but it has become a problem for testing. While running the core, I have the UE connected and I’m transmitting video but once too much memory has been used the SMF sort of locks the machine making it impossible to interface with or send data over. At that point it requires a manual shutdown. Is there a way to disable this memory retention?

Hi, I think this problem is similar to SMF consuming all VM memory.
Hope this Q/A can help you.

It could possibly be. I don’t see the same 409 Conflict messages listed there. I do see a lot of these:

[INFO][UPF][PFCP][LAddr:upf.free5gc.org:8805] serveUSAReport
[WARN][UPF][PFCP][LAddr:upf.free5gc.org:8805] handleSessionReportRequestTimeout: SEID[0x1]

Why does the SMF retain everything in memory? Why not store it and reference later?

Hello, in the current free5GC implementation, manual release is the only solution to address this issue. The SMF requires a release message to properly free the resources. However, I will report this problem for a future fix.