Roon emits memory usage to its log file every fifteen seconds… Granted, that’s just the RoonServer process and not RAAT. But do the numbers jive with what your script is recording? (On my Roon Core, the numbers Roon records match with what the OS says RoonAppliance is consuming. But I also haven’t observed runaway memory leaks, either.)
Also, your output suggests you are reporting the virtual alloc, not actual physical used. On my Roon Core, virtual alloc is ~10x actual resident physical used…
Hi @cwichura and thanks for putting my lazy effort on the spot
My figures are indeed the virtual allocation and I see the log figures you mention: 08/12 13:27:10 Info: [stats] 5459mb Virtual, 1228mb Physical, 403mb Managed, 0 Handles, 72 Threads
The log number for Virtual tracks my RoonAppliance figure, virtual memory for RoonServer and RAATServer are constant so far. I have a TODO or two in the script anyway and have been thinking of log scraping to piece together activity. Now thinking that might be all I need. Expect a better effort before the weekend.
So I’m going to write a better memory reporter this evening, a good chunk of the way there already. There is already enough from the original to make some observations. Of the four Roon processes three seem to be basically well behaved, RoonServer, processreaper, and RAATServer have the same virtual mem allocation as they did 36 hours ago. The same can’t be said for the RoonAppliance process, this started with 5575056K and is now at 6563156K. While the figure does fall back on occasion there appears to be an upward trend.
That’s exactly my observation. What I haven’t been able to determine is what activity on the server exactly is what impacts most… just playing back, following cross-referenced metadata, adding music to the library, etc.
I think there may be a garbage collector at work when memory alloc falls back, but nevertheless the longer it runs, the more memory will be allocated. The other processes don’t vary a byte…
I can confirm that it seems to loose a little size when I’m asleep, but that’s a pretty small window. While it’s in use there’s a gradual accumulation.
One thing I’ve noticed is when playing from Qobuz, Roon downloads the entire track into memory and then frees it when it moves to the next track. So depending on the length of the track, you get ~100MB pendulum swings as each track plays. But it very clearly releases the memory for each track when its done playing the track. (I suspect Roon probably loads the full track into memory no matter what the source is, even when coming from local storage.)
If the case of the garbage collector, you’d see the “Managed” number in the log outputs increase and then drop when GC runs.
Done the work to update the memory usage, and tidy the processes reported on, not done with log scraping yet but will get some time soon. It now looks like this:
@cwichura these are now identical to the log figures but I’m parsing them from /proc/<pid>/statm not the log as it’s independent verification. I’m pretty sure my pendulum’s not true.
@Jacques_Distler thanks for the input, I’ve already seen the figure tick up long enough to be fairly sure. I’m curious to see if it’s possible to narrow down the activities that cause it to happen.
Now to sleep for a few hours rest for both me and RoonAppliance.
One advantage of watching the memory usage in real-time is that you can watch RoonAppliance gradually chew up more memory, even when it is purportedly idle (no music playing, no tracks being analyzed, …).
Replace “top” by “top -b -d 3600” in the above, and redirect the output to a file. You’ll get a snapshot of RoonAppliance’s memory usage once ever hour. (Change “3600” to some other interval if you want more/less frequent measurements.)
