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.
Doesn’t look like my issue is getting any attention from support. I guess I’ll just have to upgrade to 1.8
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.
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 https://help.roonlabs.com/portal/en/kb/articles/flags 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
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.
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.
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.
This topic was automatically closed after 323 days. New replies are no longer allowed.