I want to contribute an observation about performance issues with large databases, with a little insight gained from long-term monitoring of my Roon Core. My database is right now about 270k tracks, with abut 56k local tracks, and the rest contributed by Tidal and Qobuz. It is running on a dedicated Linux server using an i5-8600K and 16 GB RAM, OS and Roon on a Samsung 970 EVO Plus NVMe SSD.
With just reproducing music and using Remotes to search and browse the albums, the performance is very good. No problem at all with that. But, as soon as I intend to save another album from Tidal and/or Qobuz into the database, Roon server starts processing the Tidal and/or Qobuz storage library, a very heavy hitting process, which brings one of the processor cores to 100% and eats up lots of RAM. While this process runs, the performance of the Roon Remote is severely impacted. Interactions with the UI (button press, search, browsing albums, etc.) give no immediate feedback and can last up to several seconds. Music playback is not impacted by this.
The storage library processing time will increase with a growing database. And it will be triggered by near every intent to save new albums from streaming services into the storage database, or to delete albums from the library. It also will run ever longer with increasing running time of the Roon server. A restart of Roon server does speed up this server process, but as long as this server process is running, it will impact the performance of the Roon UI. This in my experience is the single most performance-impacting process running on the Roon server, and its impact is not really noticed until after the storage library exceeds a certain size. I wasn’t bothered by this, until my library passed 100k tracks, 56k of which corresponded to local tracks.
The log entries for the running process look like this:
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:143727497
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:143727498
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:143727499
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:143727500
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:143727501
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:143727502
03/28 17:13:53 Trace: [clumping] clumping 24 tracks and 0 auxfiles
03/28 17:13:53 Trace: [library] finished with 24 dirty tracks 1 dirty albums 3 dirty performers 6 dirty works 6 dirty performances 3 dirty genres 24 clumping tracks, 0 clumping auxfiles 0 compute tracks, 0 deleted tracks, 24 tracks to (re)load, 0 tracks to retain, 0 auxfiles to (re)load, 0 auxfiles to retain, and 43 changed objects
03/28 17:13:53 Trace: [music/searchindex] [search-index] removed in 0ms: 1 albums, 24 tracks, 0 works, 0 performers, 0 labels, 0 genres
03/28 17:13:53 Trace: [music/searchindex] [search-index] added in 2ms: 1 albums, 24 tracks, 0 works, 0 performers, 0 labels, 0 genres
03/28 17:13:53 Trace: [dbperf] flush 106523 bytes, 98 ops in 19 ms (cumulative 22955306714 bytes, 20986507 ops in 3319639 ms)
03/28 17:13:53 Trace: [library] endmutation in 85ms
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039501
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039502
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039503
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039504
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039505
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039506
03/28 17:13:53 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:5039507