Roon runaway memory usage

Hi @Neil_Jones1

Pleased to hear that you’ve solved your memory leakage problem, which was way worse than mine. I’m only losing around 0.2Gb per day, so although the end result is the same, the timescale is very different. My network setup is very simple: just one LAN, no VLAN, one network adapter card. It’s clear from other’s posts that this is a longstanding issue which doesn’t seem to be getting any attention at the moment from @support

I’m running my Roon on a Synology NAS using Synology’s native app for Roon, but I’m also running Docker on that box, so I’m interested in whether your workaround might also work for me. Maybe I wouldn’t have to use the tricky maclan part? My instance needs to see the LAN and also be able to communicate via localhost to the MQTT extension that I run in another container. Perhaps you could give me some pointers? Thanks

@Joe_Kearney I agree it’s not ideal, but my setup is not exactly a regular setup so I was willing to accept it’s my server setup that is triggering an edge case in Roon and the runaway memory usage. I have various other things installed on the NUC I use, including Home Assistant. This runs lots of docker containers for its extensions and each one creates a virtual Ethernet adaptor. That means when I run ‘ip a’ on my system it shows a total of 18 different network adapters! Only one is real as the server has a single real network card, all the rest are virtual devices created by docker or the loopback adaptor.

But, as various other people are having issues with memory usage as well it looks more likely my system setup is triggering a more extreme version of the memory leak.

Running Roon in a Docker container has allowed me to use Roon in a more ‘normal’ environment isolated from everything else I run on the server and without 18 network adaptors just like running it in VMWare isolates Roon in a more normal configuration. But it’s definitely not something that the average user would want to, or should, do.

If you want to run Roon in Docker you only really have two options regarding the networking - host networking or macvlan. Host is much easier to use and is how the various containers listed on hub.docker.com work, for example see: Docker Hub

Host mode means the container acts as if it is directly attached to the host computers network and can see everything on the network and everything on the network can talk to Roon in the container including your MQTT extension.

Be aware that if the memory usage is related to the network then running Roon like this will not solve the issue as it will still be running on your network in effectively the same way as it did before and even though your NAS only has one real network card, running docker means you will actually have multiple virtual network cards running on the system as that’s how Docker networking works.

I went the way of macvlan as this meant I can have only one network appearing in the Docker container but it is much harder to setup.

If you want to try Docker, I would recommend trying Roon in a container using the host networking option and see if that helps your memory leak. If it doesn’t then you could try macvlan, but be prepared for some network tweaking on the NAS to get it to work.

I’m not sure memory leak is related to networking. See this post (I back up to a local HDD, not one from the network): Memory leaks on QNAP - #17 by DanielAvasilichioaei
I do not exclude the variant in which there are several memory leaks, including one related to networking…

I have extreme memory growth too but I have a lot of ram. Still the more the memory usage the slower searches go and response times to clicks increase. Roon has been running for awhile now. I can simply kill -9 and it will auto restart. My library is 40K tracks. I am running on a HP ML 350, 24 CPU, 32G ram.

top - 21:14:47 up 194 days,  7:01,  2 users,  load average: 0.72, 0.31, 0.34
Tasks: 578 total,   1 running, 577 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.2 sy,  0.0 ni, 99.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 32736612 total,  1011388 free, 20893128 used, 10832096 buff/cache
KiB Swap: 16515068 total, 15873532 free,   641536 used.  5937140 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
35296 root      20   0   11.4g   5.3g 273336 S   8.9 16.9   1429:09 RoonApplia+
48

What the ram is this high things like adding an album send CPU up. Here is an example:

top - 21:21:32 up 194 days,  7:07,  2 users,  load average: 0.30, 0.23, 0.29
Tasks: 574 total,   1 running, 573 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.3 us,  0.4 sy,  0.0 ni, 94.3 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 32736612 total,   986744 free, 20882720 used, 10867148 buff/cache
KiB Swap: 16515068 total, 15873532 free,   641536 used.  5947136 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
35296 root      20   0   11.4g   5.3g 280564 S 125.0 16.9   1429:56 RoonApplia+
18

Roon software does not make use of multiple core servers very well, hence the recommendation for i7 CPU and SSD. I believe this is due to the database implementation. I have read other threads of people who have much larger libraries than I do having performance issues. You know millions of rows of data is NO BIG DEAL nowadays. Memory is cheap. Perhaps Mongo would be a good choice.

I am also unsure why library operations affect playback at times on multi CPU servers. Playback should be an entirely separate thread(s) of the application.

Anyway its time to restart by roon core and free some memory for awhile. Despite this inconvenience, I would not trade Roon for anything else. Plus I know that performance is a non-functional requirement for far too many developers.

1 Like

This topic was automatically closed after 323 days. New replies are no longer allowed.