Hi, @Mr.Flibble, thank you for sharing the update. Our dev department has an idea what can be causing this and they are working on implementing the solution. Hopefully, we’ll be able to get it out to the Early Access soon.
Thanks!
–
Ivan
5 Likes
Thanks Ivan for the update. I too have been getting similar behavior where I have to manually restart the Roon server every two days.
1 Like
Thanks @Mr.Flibble
I had lost all recollection of that thread even though I followed it at the time
1 Like
@Peter_Bruderer reminded me of it
1 Like
Just to chip in, I’m seeing the same RAM issue. My initial config in Proxmox was using 4GiB, I’ve now increased it to 8 GiB. But it’s eating up all the RAM.
It just keeps going up until you restart the service or reboot the computer.
If you can automate that it really does help, though it is a band aid until the real issue can be sorted out
I see a similar issue on my NAS running current Production (not Early Access).
Yup, I do a nightly reboot. But later in the day all the RAM is consumed.
1 Like
Ouch!! are you able to allocate it a bit more.
My 16GB system seems to last a few days, but the more music I play the quicker it gets exhausted and if I do not play music at all the memory used goes up much more slowly
I’ve been do the nightly reboot for a couple of years, most of the time that’s enough but the drop outs or server crashes continue….
1 Like
Just adding my $0.02 here also.
I am seeing the same… memory use increasing over a day or more and performance deteriorating more and more as this happens.
This on a dedicated 8GB i7 NUC running Windows 10 x64. Once memory footprint visible in Task manager gets up to 4GB or more I get big pauses all over the place. My library is only 9K tracks nd this RAM use goes up even if I don’t play anything.
Much of the rest of my ram appears to be being used by the filesystem for file cacheing as normal but that does even leave enough to start a new instance of Roon client on the server without serious paging.
Memory use by Roon has been a big issue for a very long time. Sometimes it gets better with a release then it seems to get worse again with the next of next-after release.
I can see no justification for this enormous footprint. leave things in files and just table the references… the filesystem is much better at handling this sort of caching.
Typical web-browsers are capable of handling much more data with much less RAM footprint and CPU hit.
2 Likes
Might be worth continuing this here
So I am playing with the settings on the two Roon Server files and it looks as if on day 1 it has improved things at least a bit, enough for me to try changing the second one just now and restart the service again.
I am not suggesting making the changes, but it could be worth watching where this goes with feedback from Roon staff as well. You cannot make these changes on Rock, but you can on DietPi, so I thought it would be worth putting a small amount of effort into testing it out.
Her is the original json file from /opt/RoonServer/Server/RoonServer.runtimeconfig.json
{
“runtimeOptions”: {
“tfm”: “net6.0”,
“framework”: {
“name”: “Microsoft.NETCore.App”,
“version”: “6.0.0”
},
“configProperties”: {
“System.GC.Concurrent”: true,
“System.GC.Server”: false,
“System.GC.RetainVM”: true,
“System.Reflection.Metadata.MetadataUpdater.IsSupported”: false,
“System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization”: true,
“System.Runtime.TieredCompilation”: true
}
}
}
The changes below are in bold, and I like to make small changes and monitor the outcome for 24 hours
{
“runtimeOptions”: {
“tfm”: “net6.0”,
“framework”: {
“name”: “Microsoft.NETCore.App”,
“version”: “6.0.0”
},
“configProperties”: {
“System.GC.Concurrent”: true,
“System.GC.Server”: true,
“System.GC.RetainVM”: false,
“System.Reflection.Metadata.MetadataUpdater.IsSupported”: false,
“System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization”: true,
“System.Runtime.TieredCompilation”: true
}
}
}
I just made the same changes to /opt/RoonServer/Appliance/RAATServer.runtimeconfig.json
I won’t post an updated graph now is I made the change about 21 hours ago and it possibly wasn’t enough to show a true difference but I will let it run for the next two days and I will post iit then should it be conclusive. If not I will change it back and wait for an official fix
1 Like