Roon runaway memory usage

Core Machine (Operating system/System info/Roon build number)

Intel NUC7i5BNH
Debian 10 x86_64
16GB Ram
Roon 1.7 Build 710

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Roon is connected via Ethernet but network details are:
Ubiquiti Unifi UP-AC-LR
Ubiquiti Unifi UP-AC-Lite
Ubiquiti Unifi Security Gateway Router

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Linn Sekrit DSi
2 x Raspberry Pi 3 running Roonnbridge
Redstone Audio Redkey connected via USB

Description Of Issue

Randomly Roon will consume all Ram available on the server it is running on and crash the entire system due to Ram starvation.

You can clearly see the runaway memory consumption in the logs such as:

02/07 13:21:25 Info: [stats] 17909mb Virtual, 14862mb Physical, 14427mb Managed, 0 Handles, 88 Threads

The sequence of steps was:

  1. Server was rebooted (due to another issue with Roon where it was consuming 200% CPU and not responding).
  2. Play some music from Qobuz to my Linn Sekrit
  3. Leave it alone for a while
  4. Find out the server is now not responding and reboot again (by pulling the power, as the server will not respond to anything due to no memory available)

This issue happens randomly and always results in having to hard power off the server to get it back again.

I can provide log files of the issue happening on request (don’t really want to post logs to a public forum).

(Edit: I mistakenly put the Roon 1.7 build version as 571 originally, it is actually 710 which I believe is the latest)

Decided to extract the memory usage from the Roon logs files and plot it over time while waiting for a reply from Support.

You can see it starting up and then initially settling on ~2GB memory usage (which is normal for my install) and then it starts climbing from 11:42 until it has finally allocated all available memory at 13:15. This charts shows the reported physical memory allocation.

There are some drops which are probably due to garbage collection happening, as Roon is .NET I believe which usages automatic garbage collection.

When whatever this condition is has been triggered the end result is always a hard crash due to memory starvation of the system. It started to happen again later the same day, but I was watching the server and noticed this time and restarted the Roon process when it had got to 4GB memory usage. It’s been behaving itself since then.

1 Like

Interesting. Are you plotting Virtual memory?

I’m running Roon Server on Arch Linux. My installation seems to level out at around 2.3 GB, but no spikes. Here’s a quick but sloppy histogram of virtual memory usage for Roon v1.7:

[root@netbook Logs]# perl -MPOSIX -ne '$m{POSIX::round($1/100)*100}++ if /(\d+)mb Virtual,/; END { printf("%5d %5d\n", $m{$_}, $_) foreach sort {$a <=> $b} keys %m}' $(grep -l 'Starting RoonServer v1.7' /var/roon/RoonServer/Logs/RoonServer_log*.txt)
    8   400
    4   500
    6  1200
    6  1300
   12  1400
   16  1500
   15  1600
  156  1700
   53  1800
   29  1900
  475  2000
   54  2100
 1636  2200
  175  2300

Here’s the same for v1.8 (in case you’re curious to know if there has been a significant change):

[root@netbook Logs]# perl -MPOSIX -ne '$m{POSIX::round($1/100)*100}++ if /(\d+)mb Virtual,/; END { printf("%5d %5d\n", $m{$_}, $_) foreach sort {$a <=> $b} keys %m}' $(grep -l 'Starting RoonServer v1.8' /var/roon/RoonServer/Logs/RoonServer_log*.txt)
    4   700
    2   800
    7  1200
    6  1300
    8  1400
   16  1500
   25  1600
   17  1700
   13  1800
  627  1900
  784  2000
  454  2100
 2448  2200
 2960  2300
 2977  2400
  631  2500
    4  2600

But, I’ve not seen this runaway memory behavior yet. I wonder what might be causing it…

Plotted virtual, physical and managed on this one as reported by the Roon logs. Doesn’t show much other than the march towards memory exhaustion :grinning:

I did do a search in the forums and found a support request from another user who seems to have seen the same issue as myself, but he was running in a VMWare host rather than directly on a physical server. Unfortunately there’s nothing in the forum post that can help me as the conversation appears to have gone over to direct messages.

Hi Neil, on the support thread you mentioned from last November, the Roon Server logs were solicited by Roon support, and it seems as if after that there was no follow-up. That is consistent with other users’ experience with their reports of ever increasing memory usage of the server. I have made that experience, too, and it has never even been acknowledged by Roon support staff. I have never experienced a runaway memory consumption, though, leading in hours to a server crash. In my case, and in several other users’ cases, memory use is growing for several days during playback and album search, etc. When it hits about 5500 MB physical memory use, the interface on Remotes becomes unresponsive, page load times go up, search times go up, and the Roon Server process has to be restarted to bring things back to normal. This, as I say, has been reported by several users, but there has been no meaningful support response. I have opted for restarting the Roon server process on my Linux core machine preemptively, avoiding the impact further memory usage increase by the server would have on the usability of the user interface on the Remotes.

1 Like

I am wondering if this is what happen on ROCK to from time to time. There are times when Roon just stops pulling anything what ever area you go to you get the Roon bouncing logo. It’s sticks for up to a minute then it’s back to normal. It’s always when I have been busy searching and playing when it occurs.

Doesn’t look like my issue is getting any attention from support. I guess I’ll just have to upgrade to 1.8
when it is released later today and hope the problem is fixed.

The memory usage is still completely out of control with version 1.8.

I noticed the UI was not responding and stopped the process before it completely killed my server but it had already got to 10GB of memory allocated.

Screenshot from 2021-02-10 12-21-30

I could really use some help from @support here as I’m unable to have a stable working Roon system without it hard crashing the server it’s running on.

Can you try to disconnect Core box from a network once you finished playback to see whether mem usage starts to rise again ?

I can try but I’m not sure what that will show as I hadn’t actually tried to play anything since the Roon Server process had last been restarted in this last occurrence of the issue with 1.8 installed.

In the last instance with Roon 1.8 the sequence of events was:

  • Restart Roon Server process on the server at 03:00 (auto restart I added in a last ditch attempt to get a usable system)
  • Roon was left idle and untouched, no browsing with the UI or attempting to play music.
  • At approx 11:20 the memory usage started to climb.
  • At approx 12:15 I loaded the Roon UI to try and play some music and it was unresponsive.
  • At this point I connect to the server and see the RoonAppliance process using over 100% CPU and having allocated 10GB memory. I then killed the process.

Playing music seems to be does not seem to be the trigger as it can go into this runaway memory usage when it is sitting idle after a restart.

It can leak anywhere, so I’d like to narrow this down as much as possible. Given the fact it is happening to you and not hundreds of people makes me think there might be an environmental trigger somewhere. Excluding network from the picture will reduce the scope considerably since we use it in a lot of places and even without user’s input, think of a discovery ( remotes, audio zones etc), metadata updates and so on.
As for playback, based on the first post I was making an assumption this was a necessary step to get the mem growth going, if not - please ignore that part.

As the server Roon runs on also runs Plex Media Server, keeping it unplugged from the network for an extended period would cause a riot from my kids.

So I’m currently trying a different approach.

I have put my Roon Server into a Docker container running on the same server. The container is running Debian 10, just as my host system is, and is connected to the network using --net=host. I’ll run that for a while and see if the same issue happens. The advantage being you can limit maximum memory on Docker so if it does runaway it won’t lock the host completely.

If it does show the same issue, I can then do things like disable the docker network interface etc and keep trying until I narrow it down without taking my kids Plex Server away. It also means I can provide support with a copy of the environment if it goes wrong and is reproducible and possibly get a memory dump of the Roon process as I should still be able to access the server rather than being forced to power it off and on again.

If it doesn’t go wrong then it shows it’s something on my host server. I then have a choice of trying to reproduce on the host or just keep running it in Docker.

Does Roon have any additional log levels I can turn on? I followed the instructions at but the logging still seems a little light.

As a Software Developer and Software Architect for over 25 years, I can’t tell you how many times a very detailed verbose logging level has saved the day :grinning:

Hello Neil_Jones1

I found this thread after searching for Roon memory leak information as I had noticed my Roon server’s memory utilisation was increasing.

However when I went to look at my server again I found it had freed up a whole load org memory at 5pm on Friday, which coincides with me using Roon to power off my Linn streamer.

Just wondering if Linn streaming could be the common link here.

All the best



I am having the exact same RAM issue. what appears to be random roon starts to use up all the Ram i have on my Nas.
I have a ds918 with 12GB of from normally roon uses about 1.5gb but once it starts using up ram the amount its using never drops and in the end crashes.
Was their a fix found?

It’s not like this hasn’t been reported before @vova

I can’t be certain, but I believe it’s an issue somewhere in the Roon networking. I had to take some quite extreme (read as ‘very geeky’) steps but Roon now runs happily for me.

I’ll go into some details.

My Roon Server runs on a Intel NUC which is not dedicated to it, but also runs other applications and services. Due to this it has multiple network adaptors visible (some real, some virtual). After having the memory problems with Roon installed directly on the server I then put Roon into a Docker container connected directly to the host network, but I still had problems with the networking (unable to reliably cast to Chromecast devices among other issues) as Roon could still see all the other network adaptors and was having issues with this.

So I decided to run Roon inside Docker with the ‘macvlan’ networking option of Docker. Macvlan is not easy to setup but has the advantage of meaning Roon can only see one network even when I have multiple network adaptors. Therefore I basically isolated Roon in it’s own little world but still able to see my network and hide everything else running on my Intel NUC away from it.

After doing this Roon has been working perfectly for me with no runaway memory usage. It has the added benefit of decreasing the idle CPU usage of Roon that was spiking a lot before. It really does seem that having Roon on a server with multiple networks adaptors causes issues and can trigger runaway memory usage and high CPU usage.

I don’t recommend what I did for most people, as setting it up is not easy, but it did mean I got a happily running Roon Server.

1 Like

I was having to reboot my Roon server once a week when I was running it natively on a NUC with linux as it was leaking memory faster than Boris’s girlfriend with a home decorating catalogue.

I’ve installed vsphere on the NUC and Roon happily runs under an Ubuntu VM with 1vCPU and 2GB RAM.

VMware is a great idea. For free as well in this config.

Using VMWare is a simpler way of doing what I did with Docker - giving Roon a controlled environment in which to run. We’ve both basically done the same thing to get it working. I only used Docker because that’s what I had available and I’ve got a lot of experience of using it.

Giving Roon it’s own system to run on, whether real physical hardware or a virtual system, seems to be the most reliable way. Running it on a shared environment seems to trigger issues.

Now I’ve got it running reliably, I’m very happy with Roon.

Same issue on MacOS - Roon is sitting at 3.2GB right now and is becoming unresponsive.

Running the app in a container because of a memory leak is a ridiculous solution, btw and you shouldn’t be satisfied with that.