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.
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
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.
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.
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.
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?
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.
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.