I replied to @Daiyama who said he was using a small library. I have ~10,000 tracks stored locally on a 2TB NVMe PCIe M.2 2280 SSD in an external Thunderbolt 3 enclosure.
I guess you think us folks with libraries that we can actually listen to in our lifetimes should not be contributing…
far from it… just that a large library is going to tax a system more than a small one so some detail is desirable.
1,5 h of listening to a radio stream and I am at 9 GB, but runs stable so far.
I think it’s also the case that the more data the better, because there’s clearly something odd about Daiyama’s system. For example, I have about 195K tracks and my memory usage (after running my core for just over three days) is 6.05 GB. My database folder size is a lot larger that wizardofoz - around 25GB - but I imagine this is down to local artwork.
Short version: the fact that Daiyama’s core is using 9GB after just one and a half hours of use is anomalous.
Now I am at 11 GB, crash is coming closer. 
Roon 918 is besides Genelec SAM 4.0 software the only one I am running on the M1.
Can you run Roon without running Genelec SAM 4.0, just to see if it makes a difference?
Now fluctuating between 11 an 15 GB with no effect on listening.
Ok, I did. this, stopped GLM 4.0 and restarted Roon and not doing anything now with Roon, let’s see what is happening.
It may well make no difference, but as it’s the only other piece of significant software running on your core it’s probably worth trying.
Yes, the M1 is otherwise completely blank. Installed only Firefox which is not running at the moment.
Started at 1,8 was at 4,8 within minutes and now at 5.8 without doing anything.
Will check status again later, have some errands to run.
I did not use Roon for 5 hours and now I am at 8.6 GB.
Check again later.
Definitely time to raise a support ticket, if you haven’t already done so.
@Daiyama, we are aware of an issue which may be causing the behavior that you are observing. We don’t have a permanent fix yet, but do have a workaround which should solve the problem. Please perform the following steps on your core:
Roon / RoonServer
Database -> Orbit
orbit_v3.db
We’ve found that we have a housekeeping process that is misbehaving and leaking memory once it gets into a bad state. Deleting that folder will reset that component back to its default state and get it back into a good state. This will have no impact on any part of your music library or configuration of your Roon system.
Please give that a try and let us know if it works.
This also seems to be helping with my memory leak. Nowhere near as fast as @Daiyama’s, but annoying nonetheless. One quick question though: you mentioned that there should be three subfolders in Database → Orbit, but I only have one, i.e. orbit_v3.db. I presume this isn’t indicative of a problem?
Not a problem at all. That probably should have read, “up to three folders.”
I need to go back and check mine then. Iirc it was a file.
But I’m not at home right now so will have to wait
Update yes it is indeed a FOLDER - was sure I read or saw file somewhere a while back. I blame Covid, which I just recovered from.
I had Covid last September - it took me about 3 months to get rid of the brain fog.
As for the folder: since deleting it yesterday RAM usage has varied between 4.8 and 5.4 GB, but it always drops back down to 4.8. There may well be something I’ll do that will trigger Roon to leak again, but for now it’s looking good.
Hi Andrew,
thanks for this workaround. 
Worked for me, I started at 1.18 GB and I am after 6 hours at 1.4 GB. So let‘s see how this develops over the week.
Roughly 30 hours, 1.67 GB and system runs much more stable. 
So happy I found this, runs Roon 1.8 Build 918 on a 2014 Mac Mini i7 16GB memory, only had this issue post I upgraded to Monterey, was miserably dealing with track skipping, remote disconnect/reconnect for almost a week
Deleted the orbit folder per instruction and been hours running rock solid, it won’t stand >5min without track stopping and lost connection prior to this
