Thank you for all your patience!
I love ROON so much, and want to enjoy music with the great sound quality and fantastic ease of use you guys provide!
Thank you again!
Michael
Hey, @brian et al - I wanted to check in and ask what the current best practices are for setting up a Roon server to handle an abusively large library (640,000 tracks and growing). They may not have changed since the recommendations earlier in this thread, but I thought I should ask fresh before ordering hardware.
My home Roon setup (with a moderate 40k tracks in 3100 albums) remains snappy running on an Ubuntu-based server (Haswell-era Xeon, music in a local ZFS pool). But the library at the work radio station, the result of years of collective scrounging, now runs over a half-million tracks andā¦ Roon often gets sluggish.
There was a significant speedup somewhere a few releases into Roon v1.3 - thanks to whoever did that work, unless it came mostly from inherited Mono improvements - such that searches no longer hang for minutes at a time, but now usually just seconds. Butā¦ Iām wondering if better optimization of the hardware (and if absolutely necessary, OS) environment would offer noticeable further improvement.
The current station RoonServer instance is running under an Ubuntu LTS on a machine with a single SATA-interfaced SSD and an Ivy Bridge-era Xeon, with the track storage CIFS-mounted from a NAS. Clearly, there are multiple places for improvement there, but Iād love some guidance about what to prioritize.
I plan to build a machine for this with internal spinning drives for the music store, just to reduce network dependencies (and RoonServer seems to notice tracks added to the tree more reliably when the storage is local). The NAS will still be the master music repository, but Iāll rsync changes into the RoonServer machine as necessary.
It sounds as if high-end desktop CPUs are favored over server ones (which seem to lag a generation behind the desktop releases). When choosing CPUs, how would these characteristics rate in order of importance?
- maximum single-threaded speed
- overall multi-threaded throughput
- number of available threads
- number of available distinct CPU cores
- amount of on-chip cache
Have any of the new AMD CPUs been outperforming Intel when running RoonServer?
Iām assuming that an SSD with a faster interface than SATA would be in order for the Roon database.
Would it also be useful to direct the Roon logs to a separate drive?
As for the OS for this to run onā¦ I have a strong preference for something Linux-based (for maintainability, stability, and ease of setting up file synchronization); but if you-all believe that Windows and native .NET still have an edge over Linux and Mono for this size library (and that said advantage is likely to remain for at least a year or two), Iāll bite the bullet and build a damned Win10 Pro machine.
If something Linux-based might be near parity with Windows in performance - is ROCK flexible enough to set up in this expected shape, or would a general-purpose Linux distribution work better?
Is there any advantage to more than 16GB or so or RAM? I figure once I start researching motherboards, Iāll aim for a configuration which fills all the parallel banks.
Andā¦ what have I forgotten to ask?
Thanks!
2 Likes
Maximum single-threaded speed in the core is the main determinant in user experience snappiness.
Multiple cores helps with running more zones in parallel with more DSP and will complete stuff like audio analysis faster. I wouldnāt go beneath 4 cores/8 threads for this use case. You could do more, but added value will diminish depending on how much you value those aspects.
I understand the preference for Linux (and wouldnāt want to run Windows if I could avoid it), but in your shoes Iād do an A-B test and come to a personal understanding of what the differences are before making up my mind. It costs nothing but a few hours to install Windows without activating and learn the situation.
Hereās my feeling: Despite ongoing improvements to mono and more and more code from Microsoft.NET being merged in, Microsoftās garbage collector is still better at handling the massive in-memory object count that comes with a library of that size. For most libraries the gap is negligibleāthereās just some design choices in that GC that start to become more painful around 4-5mm objects on the heap, and really large music libraries can push things that high.
I donāt think Microsoftās GC is ever going to make it into Mono. I think instead theyāre going to keep making .NET Core better until Mono is displaced. At some point they will reach a point where we can switch to .NET Core. I have a hard time imagining Microsoft doing that and us being able to start that effort until a least a year from now, but it could be more depending on whether .NET Core 3.0 is actually viable or we need to wait another iteration.
In other words: if you didnāt have a strong preference for Linux, Windows/Microsoft.NET is the safer recommendation at this unusual scale. Since you do, it may be worth the extra few hours to try it both ways and see, just in case the Linux performance on a fast machine is good enough and you can avoid the Windows headache.
As for other hardware choices:
-
High-End Desktop vs Server CPU: High-End Desktop. Especially now that there are Threadrippers and i9ās, thereās no reason to buy a Server CPU for something like this unless you need Server motherboard features like redundant power, remote admin, etc. 4 Cores/8 threads is probably fine. You could go up to 6-8 cores especially if you see yourself running more zones/dsp.
-
Intel vs AMD: We test, develop, and ship hardware based on Intel, so thereās some passive bias. That said, AMD might get you more performance for the same $. I have a very, very fast AMD machine here (built for batch processing/machine learning) that runs Roon very well. I wouldnāt worry about it too much.
-
NVMe SSD is a good idea. Larger sizes tend to be faster, too up to a point. Samsung 960 Pro is very good.
-
Definitely store the music on local (USB3 or SATA) drives and stop watching the NAS. This will help more than you think.
-
For 640k tracks Iād consider going to 32GB RAM. Even if Roon doesnāt use it all, youāll benefit from extra filesystem caching + more breathing room.
-
If you wanted to try ROCK, NUC7i7DHNE is the best NUC right now. You can hang USB drives off of it and it will support the storage. It can take an NVMe SSD and 32GB of RAM. So it could work.
-
If you want to build an even bigger machine, run Ubuntu or Windows. Getting a shell on ROCK is more difficult if you want to do sysadmin stuff like setting up cronjobs, rsync, etc. So that may push you in other directions.
That covered what I can think about right now. Any more questions/clarifications, let me know. Iād like this build to be a success for you.
18 Likes
Thank you very much! That was a thorough answer, delivered admirably quickly.
If Iām bothering to do this upgrade, I expect Iāll go ahead and build it into a box which can fit the spinning disks internally so they can be connected by SATA rather than USB3. I associate USB interfaces with high overhead even if USB3 offers high bandwidth; although maybe thatās a prejudice left over from an earlier age.
Oh, what was the end of the thought which began āSamsung has a goodā¦ā?
Also, if Iām bothering to do this upgradeā¦ I might as well actually hear your advice to try Windows. I have Win10 Pro N media I can bust out, and Iāve already been through the exercise of learning where to turn off some of the most egregious unnecessary cruft. If Iām to survive such an exercise without cursing so much that I burn my desk to ashes, Iāll have to find a good Unix-flavored tool set, especially for SSH and file copying. I hear this rumor that Microsoft is actually supporting some Linux applications with a compatibility library of their ownā¦ if that actually works, and I donāt have to install Cygwin, maybe this could be less terrible than usual.
And Iāll have to keep my ear to the ground for a particular combination of Intel-CPU motherboard and NVMe SSD models which are known to work well together, since I think Iāve heard about some incompatibility nightmares in the field.
I would think it was going to proceed along the lines of ā¦ track record or history of stable performance and reliability. 
I was going to call out the 960 Pro as a quality NVMe SSD (edited above to fix)
Iāve never run into a compatibility problem with an NVMe SSD, and have installed several at this point on both Intel + AMDātheyāre simple machines. Just PCIe on an alternate connector.
I donāt think USB3 is a real negative for media storage other than the additional boxes/cables. Maybe some background stuff you barely pay attention to will go <5% faster? Thatās about all Iād ever expect. USB3 is fast enough that the drive should be the bottleneck. Of course if youāre using a larger case/motherboard and not a NUC, go SATA.
I havenāt played with Microsoftās Linux support much, but it looks like it might work now that theyāve solved the filesystem bridging stuff. Another option would be to use Docker for Windows + expose the media drive to a docker container as a volume. Cygwin worksā¦it is just slow and kind of annoying.
1 Like
Hi Brian,
that is an intriguing comment. My music is split between USB drives and a NAS. Is this an issue only for those with very large libraries or does it affect everyone regardless of library size?
I hate NASās for music storage. I know that some people like them/need them, and we do support them, but I wouldnāt use one for Roon (or any software trying to manage 50-100k+ music files) for myself, regardless of library size.
They donāt support real-time watching for file changes very well, scanning them over the network takes 10-20x (or more) as long as a local disk. Because they donāt support filesystem watching very well, you pretty much have to scan the whole folder tree periodically to avoid missing changes.
Also, because networking is in the mix, thereās a whole litany of extra broken states they can get into, ways they can confuse the OS or the software, and weird behaviors that they can exhibit. Performance varies greatly from product to product, and sometimes the performance can be so bad that it causes major behavioral problems.
On some networks, or with some NASās, the connection to the filesystem bounces up and down several times a day, or more often, triggering Roon to re-scan the folder tree too many times.
With a large library, sometimes you can end up with Roon spending a decent fraction of the time scanning over the NAS for changes because the connection is bouncing up and down or just because it takes so long to walk the folder tree that the periodic scan every few hours (frequency is configurable) turns into Roon doing work a serious fraction of the time just to keep tabs on your files.
I keep my music on a USB drive hanging off of a ROCK-based NUC. Itās something I never have to worry about, and I like it that way.
I do use a NAS for a backup copy/archive of the music, and for some other stuff like video streaming where the much lower file count makes most of the disadvantages disappear.
15 Likes
Thanks Brian, the team Roon hatred of all things NAS is fairly well known. I am surprised that you support Roon core running on a NAS under the circumstances but I suppose that removes some of the network related issues with scanning. Now to search for that thread which states how big a spinning disc I can get in the NUCā¦sure it used to be 2TB but might be 4TB by now?
withdrawnā¦
With a 500K track library you are almost certainly into the multiple 12TB spinning drive scenarioā¦ I an out space at 12TB drive for a measly 200K library. This has meant back to NAS as my windows based i7-7700 fanless chassis will only support 1 x 3.5" drive ā¦ and it was a noisy drive tooā¦so I am looking at another option perhaps raid 0 based external USB3 or splitting my music over 2 volumes. My NAS is 6 x 6TB raid 5 or another 2 x 12TB JBOD that back up each other
Hi Tony
It depends on the physical size of the drive, not the capacity.
The drive can only be not higher than 7 mm, so most (if not all) drives with more than 2 TB are too high to fit in the NUC 
Thanks but 70mm? Are you sure, sounds massive, the NUC is about that tall itself! thought the limits was more like 9mm or so? I have the 7i7BNH which is quite slim.
Sorry, you are right. I meant 7mm and I changed it in the posting above 
No probs, the spec says 9.5mm, which means a laptop type drive will be required (7mm), as all the others are usually 15mm.
Apologies for going OT!
Yeah, none of the stuff I was complaining about really applies if you are runnnig Roon on the NAS itselfāsince then there is no networked filesystem involved.
The main caveat with running roon on a NAS is that many of them have underpowered CPUs, and it is easy to end up with Roonās database on a spinning disk, which isnāt greatā¦but both of those are surmountable by making good hardware/configuration choices.
Hey Brian. Forgive this silly question.
But does this ~500k number only apply to 500k locally stored files or does the same apply to a Roon library that had 500k Tidal tracks?
Or does it apply equally to both?
Assume that all background audio analysis has been fully completed for a 500k locally stored library.
Equally to both. Database works just as hard in both cases to manage the contentā¦
2 Likes
FYI
I run a large library on 4x6TB in a USB3.0 box. Raid 0.
Backed up to several NAS and other USB drives.
Works very well with snappy responses with all tasks.
I have 6x6tb in my nas as shr and about to add another 2 x 6tb drives one for data and another as spare
My other nas has 2 x 12tb jbod as backups. I have maybe 10 other 6tb drives around for other backupsā¦Iām well sorted 