I guess I’ll join in on the “Me too”.
I’ve been fighting with major slow-downs for many months, generally triggering when the RoonAppliance process uses more than 4.5GB of memory (not counting shared memory). It seems like the problem became more and more noticeable as I grew my library.
When roon starts getting the major slow-downs I notice it constantly updating metadata. Click in the UI and nothing happens until a bunch of the currently running metadata updates complete. Once it starts the playback everything is smooth for that one file, but as long as there is any sort of metadata thrash going on in the background Roon shows 5-60 second delays in any playback related action (pause, skip, shuttle, etc).
At some point I ended up setting up a docker-compose restart cron that fires off every Monday, Wednesday, Friday, and Sunday.
0 11 * * 1,3,5 cd /home/docker/personal/appstack && /usr/local/bin/docker-compose restart roon > /dev/null 2>&1
0 15 * * 7 cd /home/docker/personal/appstack && /usr/local/bin/docker-compose restart roon > /dev/null 2>&1
I’d rather take 15 minutes of application restart downtime every other day than deal with the constant thrash and lag that letting the service run without regular restart generates.
This is Docker, so my host OS shouldn’t matter terribly. But, just for completeness sake, host OS is Ubuntu 18.04 running Kernel 5.4. docker-compose config as follows (ips masked):
version: '3.5'
services:
roon:
container_name: roon
image: steefdebruijn/docker-roonserver
restart: unless-stopped
environment:
- TZ=America/Los_Angeles
networks:
docker-vlan2:
ipv4_address: x.x.x.9
hostname: roon
devices:
- /dev/snd
volumes:
- roon_app:/app
- roon_data:/data
- /media/music:/music:ro
- /media/roon/backups:/backup
labels:
- SERVICE_IGNORE=true
dns:
- x.x.x.1
volumes:
roon_data:
external:
name: roon_data
roon_app:
external:
name: roon_app
networks:
docker-vlan2:
driver: macvlan
driver_opts:
parent: vlan2
ipam:
config:
- subnet: x.x.x.0/24
System resources are very much so not a problem. Got much more RAM than needed. Heck, roon could eat 64G and I wouldn’t notice as long as it was performant.
# free -h
total used free shared buff/cache available
Mem: 125G 49G 70G 5.6M 5.7G 74G
Swap: 4.0G 32M 4.0G
The disk access speeds for where the DB lives are also not a problem. Database (and all roon files except music) live on a 512G Samsung 960 Pro NVMe SSD. 2+GB/s should be more than enough. Ignore the fragmentation, the majority of it here is caused by metadata from Roon and Plex, but shouldn’t impact overall performance of ZFS because of free space on pool as well as NVMe.
$ zpool list rpool
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 476G 246G 230G - 58% 51% 1.00x ONLINE -
$ zfs list rpool/docker
NAME USED AVAIL REFER MOUNTPOINT
rpool/docker 210G 90.3G 166G /var/lib/docker
Music files live on a 25.2T ZFS RAID10 made of 4 WD WUH721414ALE6L4 connected to a 16-port LSI SAS2116 controller, with sequential read speeds in the 250-600MB/s range. The pool is only used for music and very low access data (deep storage).
$ zpool list stardom3
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
stardom3 25.2T 19.2T 6.09T - 7% 75% 1.00x ONLINE -
$ zfs list stardom3/music
NAME USED AVAIL REFER MOUNTPOINT
stardom3/music 10.3T 5.30T 10.3T /media/music
Processing power also should not be a problem here. Running an 8-core (16 thread) Intel Xeon D-2146NT with a fifteen-minute load average of under 1.0 at most all times. The only thing roon does that requires more power than a single core can provide is up-sampling of music to DSD512, which I only tend to do for testing purposes.
Edit:
Forgot a few details.
Database size:
# du -sh RoonServer/Database/
30G RoonServer/Database/
Library size.
# du -csh /media/music/lossless/ /media/music/lossy/
6.7T /media/music/lossless/
347G /media/music/lossy/
7.1T total
