Memory leak with Roon 1353 on Debian

I believe I’m still seeing a slow memory leak with Roon 1353 on Debian (Slim/Bookworm). Anyone else seeing similar?

I am running on Ubuntu 22.04 LTS server and it’s only been 6 hours since I’ve been running the new build, so it’s still early days… But… my first impression is very positive…

Roon Server started up with lower baseline RES memory size than before, with noticeably lower thread count, snappy performance. Seems that garbage collection is much more aggressive; at the moment my server is running its first background process which I know was previously very memory intensive (Qobuz storage library processing), and when before this made RES memory size go up to 9 GB and more, it now sits around 6.5 GB…

As all this is quite dependent upon the library size and complexity, I’ll add that I am nearing 300k tracks, 56k of which are local, the rest Qobuz and Tidal.

I’ll also say that for the last few months I have been running with swappiness=0, as I feel to a positive effect. Still, making any meaningful assessment of memory utilization of this new build will require a week or two…

Edit: I forgot to mention that back in September @ben asked users on another thread to test setting the environment variable DOTNET_gcServer=0. I ever since have been running with this variable set, and it is still set now after the update. @ben, whatever you have done to improve the Linux server’s memory management, my first impression is very positive indeed! Can I now unset that environment variable, or should I keep it set or doesn’t it matter one way or the other?


My Roon server has now been running for more than 10 days on the new B1353, and my first positive impression holds. Memory management on the server has significantly improved. Interaction with the system make the memory footprint go up over the day, but by far not as much as before. And, like before, the daily backup every morning brings it back down.

Ten days ago I unset the experimental environment variable, and the system has been running fine and stable. Whatever @ben has changed, has been successful and has brought the expected positive impact on the Linux server.


Thanks for the update, @Andreas_Philipp1.

I’m actually seeing similar results with a Debian Bookworm-based container. My library is much smaller. I’m seeing memory utilization stay flat at around 2GB.

It doesn’t surprise me that @ben asked you and others to play with that garbace collection setting. That setting toggles between “workstation” and “server” mode. Years ago, In the “old” days, it was supposed to be a simple choice between either one profile or the other but as the .net garbage collector matured, the lines got blurrier. Even though we’re running Roon as what we think of as a server on Linux, the workstation profile may make more sense. It’s more aggressive about keeping memory usage low. Server vs. Workstation used to also imply concurrent vs. exclusive meaning that in Workstation, garbage collection would basically cause process execution to pause while collection occurred. I’m pretty sure it’s now concurrent in both profiles which means that the choice of workstation isn’t likely to cause interruption of music playback.

Lots of conjecture here on my part but it actually wouldn’t surprise me if, among the changes they made, they just switched to Workstation for everyone.

1 Like

That’s probably the case, but it’s my impression that there is more to it. Before the recent update, even when setting the workstation GC in the environment variable, performance was not as good as it is now. And in addition, I clearly observe notably less threads being spawned by RoonAppliance. Whatever it was that has been done, it has helped a lot…

With 299k tracks in my database, my baseline RES memory usage is about 5,6G. After the update, it rarely rises above 7GB, and comes back to baseline next morning after the backup. This last point seems interesting to me, as the backup process clearly does something which releases memory. I wonder if this could give the developers some hint as to what to do with a running (maybe idle) system to release memory…

1 Like

Oh there is definitely more to it. I didn’t mean to imply there wasn’t. They clearly fixed one or more memory leaks and may very well have made other changes.