Hi,
I have added the impact of B1648 to the existing thread for consistency for B1647, and linking it here, as will add to it over the rest of this week.
However, the initial analysis is looking good, with much more controlled memory usage during the ‘Scheduled Activity’ period.
Can I infer from the Release notes for B1648 that this analysis has been useful?
Yes, thank you for your efforts and feedback.
Hi,
very interesting feedback, thank you.
I am currently running Roon Server in the official Docker container on a QNAP TS-453Be, with 16 GB RAM installed, and I can confirm that performance already feels clearly better than with the previous native QNAP setup.
My library is fairly large, around 8,416 albums, 128,722 tracks, and roughly 11 TB of music. After the initial scan, Docker has been much more responsive in everyday use, especially during searches and background activity.
In my case, memory usage is currently around 42–43% of 15.48 GB usable RAM, so roughly 6.5–6.7 GB for the RoonServer container after the initial library scan.
Total system memory usage on the NAS is around 50%.
So I will be very interested to see how much further RAM usage improves with 2.65, because even on my system the direction already seems very promising.
Best,
Nicola
We aren’t going to stop with 2.65 
This is great news 
Analysis over the last 24 hours or so
Memory usage comes up from 4.5GB to 5.25GB following the ‘Scheduled Activity’
But nothing close to the 10-15GB of memory usage in B1647
Managed vs unmanaged usage
This has all improced since the update to B1648
I have then asked to overlap GC events
And the analysis from the last 24 hours, is a bit different
During the ‘Scheduled Activity’ period there was a massive spike of memory usage, up over the 16GB level, and it looks like my ROCK server crashed and restarted early this morning.
Certainly the status screen, shows it has only been running for 3 hours or so, and I did not restart it manually early morning.
But I think there may be a problem. @noris @vova
There were no additions to my library, and only usage in the evening and not beyond midnight.
So some medadata refresh process during the Scheduled Activity period has got out of hand with a heap accumulation kicking the memory usage up to the limit which initiated a crash & restart.
I just noticed a new (to me) process running on my Mac: MonoBundle/processreaper
ps aux | grep -i roon
me 73191 0.2 12.0 49486572 4020568 ?? S 4:21PM 107:27.72 /Applications/Roon.app/Contents/RoonServer.app/Contents/RoonAppliance.app/Contents/MacOS/RoonAppliance
me 73193 0.0 0.0 41700052 5728 ?? S 4:21PM 0:00.08 /Applications/Roon.app/Contents/RoonServer.app/Contents/MonoBundle/processreaper 73191
me 73190 0.0 0.3 46702976 103772 ?? S 4:21PM 0:22.71 /Applications/Roon.app/Contents/Resources/../RoonServer.app/Contents/MacOS/RoonServer
me 73177 0.0 0.3 44895932 109964 ?? S 4:21PM 0:44.52 /Applications/Roon.app/Contents/MacOS/RAATServer
I haven’t noticed processreaper before. It’s being given the process id of the RoonAppliance.
Does this look familiar to anyone?
I’ve not experienced a random restart before.
Consider overlaying dbperf traces to your charts if you want to confirm a db flush caused that memory spike. Log lines to look for:
04/17 05:06:53 Trace: [dbperf] flush 693748 bytes, 321 ops in 25 ms (cumulative 223021508 bytes, 93494 ops in 41160 ms)
Yes, there was dbperf activity, around the memory spike and crash, but there was during the last ‘Scheduled Activity’ period
Let’s see what the next log analysis following the next ‘Scheduled Activity’ period.
Unfortunately I am not able to continue this, from Sunday, as off on a business trip for a few weeks.
Will be relying on my Roon system with ARC to support me during the trip, so hopefully no further memory spiking incidents.
It’s expected
I mentioned a random restart last week IIRC. Unusual as I have issue with zone drops but not restarts.
It’s expected and normal behavior. See the section under “Large Data Moves Across the Heap” for my take on it.
Just a data point for B1654
I don’t seem to need to restart quite as often on this build but the still get into a crappy state (laggy UI, zone drops etc) after extended periods of playback. So, my sense is that there is still an issue here.
I haven’t seen much mention of it lately on the forum.
@ncpl Away at present, so not able to access ROCK server to pull the logs and see how the latest EA build is doing with the memory usage over 24/36 hour windows, peak usage during the ‘Scheduled Activity’ period and post recovery after scan & metadata updates (Garbage collection and all that stuff)
However Roon ARC access has certainly got better with 2.65, with faster ‘wake up’, search and playback on my MacBook Air over Hotel WiFi and the 7,000km back to my Roon server and NAS music content 
Roon ARC on the iPhone is normally offline access, for plane usage - haven’t tried Roon ARC on an airline WiFi yet, could be interesting!
Let’s hope we get back to Roon 1.8 like performance levels for local content streaming, before the ‘online’ requirement blew up Roon performance, responsiveness etc. I think the Roon development team are going in the right direction here again.
Going to hold off on the ‘upgrade to 32GB’ on the NUC7i7DNK unit for now, as hopefully not hitting that ceiling anymore 
But I still reckon a port of RoonOS to a MacMini running Apple silicon M4/M5 (no MacOS) would make a great Roon server for a ROCK release. The Apple designers have taken a big leap forward over Intel on the CPU & GPU designs & silicon architecture. Maybe any required playback DSP could be directed to the GPU cores in RoonOS, as these would be spare for a ‘without video’ headless application. Plus fanless and less power consumption
Arc offline is still garbage. Many downloaded albums can’t be played (arc shows the album as downloaded but no tracks showing as visible). Album artwork on many downloaded albums is missing (or tiny). Basically the same as it always has been.
one day….
Submit some feedback in Feedback, because I don’t think this is getting the attention it should.
I think it’s there. And they know.
