MiniPC Intel NUC11ATKC4, Intel Celeron N5105, 16 GB RAM, WD Blue SN570 2TB NVMe with Linux Mint 21.1 Kernel 5.19.
Roon Server Version 2.0 (build 1234)
Networking Gear & Setup Details
Ethernet
Connected Audio Devices
RopieeeXL → DACs
Number of Tracks in Library
around 65,000
Description of Issue
Switched from Mac mini M1 to a dedicated Linux machine and quickly noticed a RAM consumption of Roon Appliance well over 10 GB. After some research I found the advice from various websites (including IBM) that some DB related processes need the Linux virtual memory (swappiness) to be restricted/be less aggressive.
After inserting the line vm.swappiness = 0 in /etc/sysctl.conf to restrict the “swapping” to an absolute minimum, the process Roon Appliance is not greedy any more! It does not grab more RAM with every action or over time but actually reduces it size for example from 3.2 GB to 2.8 GB over time.
I think this hint to set vm.swappiness = 0 in /etc/sysctl.conf should be placed at least on the website Installing Roon on Linux. I guess many outcries over memory leaks could be avoided if users are more aware and informed.
I’m not a Linux expert, but I see at here below link that 0 value disbles the swap, and 1 is for minumum amount of swapping. Did you also tried 1 value?
It doesn’t work
After a few hours the process Roon Appliance becomes greedy again. It uses more an more RAM over time without Roon being used by any client.
I am running a Linux server (Ubuntu) for a couple of years and have never seen this problem. How long do you have it running? Could Roon still be building it’s database?
Roon Server run over 24h and then reaching almost 10 GB RAM utilization.
Maybe Roon is still building the new database. Is there any indicator to check if it is? On the Mac mini I have never seen such a hight RAM consumption.
At the moment I have disabled swapping completely (swapoff -a) for test purpose. Roon Appliance stays at 1.9 GB RAM during playback, adding new albums (from Qobuz) and browsing through the library.
It can take a while of you have a lot of albums in your library.
You can look in the settings what you have set for library scanning in the background. I have set it to the lowest
If it’s dedicated you want core to use all the RAM. You paid for that RAM, use it. The only time you should care about RAM usage is if you run out of RAM or see excessive paging in/out of swap. That paging is slow. Using RAM, even up to 99% is perfectly fine if you’re not paging.
Linux is one of the most advanced OS’s for handling swap and memory. It’s supposed to leave things in RAM as it makes things faster. Also, you say 10GB RAM… but then you reference changing swap parameters. You have 16GB of RAM in your system and you report 10 used. The system shouldn’t be swapping at all. And your own graph shows swap space at 0. So, adjusting the swap parameters isn’t doing anything.
$ free -t
total used free shared buff/cache available
Mem: 8004292 5793884 357160 37496 1853248 1834720
Swap: 4194300 409088 3785212
That’s a system that needs more RAM. This is just a sample from one of my test servers but I don’t run Core here. When I troubleshoot this system I see that most of the swap in / out is because of postgresql. Because this is test, I don’t care. It just makes my database testing slower than it should be. My production servers have a bunch more physical RAM.
and here’s another system right after booting who hasn’t had time to buildup anything in cache yet so overall memory pressure is low…
total used free shared buff/cache available
Mem: 1929152 240324 1256992 1024 431836 1462472
Swap: 4030460 0 4030460
I don’t think you have a problem here. Wait until you go over 100% physical memory and then you have an issue.
The only other thing to note here is… leveldb is a special kind of DB. It utilizes memory and storage very differently than, say, Oracle or other relational SQL type DBs. just let it do its thing and you’ll be fine. leveldb manages its memory utilization on its own. Most DB2 “tuning” is referring to traditional relational DB (SQL) models which leveldb is certainly not.
leveldb tuning is fairly straightforward in Roon… the size of your lib grows the DB tree and that tree wants as much memory as you have trying to keep the whole tree in memory even if you never access those branches. When you run out of memory it will optimize the parts of the tree in memory. Or, at least, that’s my limited understanding of it.
I care how much RAM Roon uses, because it does not stop and was still consuming more RAM (using more than 10 GB). A process should not be so greedy to consume all the RAM it gets. I don’t consider such a behavior as a good implemented software (memory leaks or missing garbage collection…). Even if the machine is a dedicated Roon machine.
The Problem is not swapping at all. The problem is Roon Server uses more an more RAM IF SWAPPING IS ENABLED. If swapping is disabled (completely, not just minimized with vm.swappiness = 0), the process Roon Appliance shows a dynamic RAM allocation (goes up to 3.8 GB and down to 2.3 GB).
So maybe there is a causality … a bug?
The swappiness sysctl parameter represents the kernel’s preference for writing to swap instead of files. It can have a value between 0 and 200 (max 100 if Linux < 5.8); the default value is 60. A low value causes the kernel to prefer freeing up open files […] Swap Explanation (Arch Linux)
So if the swap is disabled entirely, then the Kernel forces Roon to free up file pages and RAM consumption goes down. The higher the swappiness the higher is RAM consumption because of more file pages open in Roon.
Swappiness won’t cure a memory leak, it’s just shuffling the memory management pack a little. Keeping memory free is not the aim of a modern Linux kernel, free memory is wasted memory that could be used for something. So you have “used memory” “free memory” and “available memory”. Used is self explanatory, free memory is just that unused and wasted in the kernel’s view. Available memory can be freed up for allocation but is been put to better use than standing idle. By pushing the swappiness down you are suggesting the system be more aggressive freeing memory up, but that may be to the detriment of performance overall.
Linux memory usage is a bit complicated as some have already described previously.
We can however calculate the effective memory footprint of a process, which I have done in the table below for the two biggest Roon-related processes and some selcted non-related processes to provide a comparison of how much memory the typical Linux system uses:
I’m not sure if you are familiar with linux, but in general it is designed to use all available memory for operations such as caching. This is simply because memory that is not used is useless memory. Also memory used as cache can be freed quickly and simple if it is needed for anything else. I find that especially new linux users would like the system to not use memory unless really really needed. This would make tha machine be slower and underutilised, but to each their own.
To see what is going on, could you share the output of the command “free -h” run on the command line?
This is/was not about how Linux ist managing RAM.
This was about how much RAM Roon (RoonAppliance (all of its sub-processes combined)) was using and allocating more and more over time.
It seems there was/is a connection to vm.swappiness, because with vm.swappiness = 0 the process(es) of RoonAppliance were not getting bigger any more. (A greedy process is not favorable as automatic caching/buffering.)
Long story short:
I was not satisfied with Linux Mint and switched to kubuntu.
Under this kubuntu installation Roon behaves as expected. With vm.swappiness = 10 it typically uses 1.8 GB to 2.8 GB RAM.
Well, now we’ll never know, since you switched the whole environment without providing data that would have shown whether it was the case.
And to know whether the amount of RAM used was for actual memory allocation by the program or the accumulation of cache during the use of the program (because accessing more files and seeing they can be caches in RAM may cause that) would require some numbers that are now unavailable.
Anyways, since kubuntu is ubuntu with a different default package selection and linux mint is basically ubuntu with a few added packets and a different default package selection, I see no huge benefit in the distro swap. Unless of course the new DE comes with a resource monitor that gives you the numbers you want to see.
Well, it doesn’t really matter as long as you’re happy.
But it’s Linux’s memory management you’re adjusting, not Roon’s. You’re stated aim of maximizing free RAM is at odds with the aim of the kernel, which wants to utilize it is all. While the headline free figure may be pleasing, it’s likely that performance suffers.
Can confirm I got the same problem. Crashed after 24-36 hours, using all my RAM (then ubuntu kills it). There is a command line edit, too Roon there you set max memory usage. Thats have worked for now. But we need to shout out some more about the problem, so Roon can fix it. It happens after 2.0 update.
I run my Roon server on Ubuntu 22.04 server, with a database of around 270k tracks at this moment. Just ou of curiosity and to observe what would happen, five days ago I configured it with vm.swappiness = 0 and rebooted. I must say it has been running well during this period in which I have been using it heavily. Will keep it running and continue to observe…
andreas@symphony:~$ free -h
total used free shared buff/cache available
Mem: 15Gi 9.5Gi 752Mi 173Mi 5.3Gi 5.5Gi
Swap: 4.0Gi 0B 4.0Gi
The only thing I’m adjusting is the vm.swappiness. Basically Linux should keep more in RAM with a low swappiness I wrote about my perceived influence of swappiness to Roon earlier in this thread…
And I repeat: It is not okay for any process to grab as many RAM as it gets until it breaks (itself or the system).
I wrote about my perceived influence of swappiness to Roon earlier in this thread…