Roon server CPU usage is excessively high (ref#LDPPXU)

Is Roon Server running?

· Yes, Roon Server is turned on and running.

What do you see on your screen?

· I see something else

When you try to connect, what screen do you see?

· I see something else

Please try to restart your Roon Server by closing the Roon app in the taskbar or rebooting your Roon Server machine.

· No, the issue remains the same

Please try to restart your network setup by unplugging, waiting 30 seconds and then replugging in your networking gear.

· No, the issue remains the same

Please select how you've connected your Roon Server to the internet

· Roon Server is connected by *Ethernet*

Have you checked your firewall settings to ensure that Roon is allowed through?

· Roon still won't connect even after checking this aspect

Have you verified that Roon Server is on the same subnet as your Remotes?

· My Remotes and Server are on the same subnet and I still can't connect

Sometimes the issues can be resolved with a reinstall of your Roon Remote app. Let's try to perform a reinstall and see if it helps.

· I've reinstalled the Roon Remote but it did not help

What is the operating system of your Roon Server host machine?

· *Linux Server* (Ubuntu, Fedora, ArcLinux...)

Select any of the following components that are present in your local network setup

· None of the above

Describe the issue

Roon server uses all cpu

Describe your network setup

I have a Grandstream router, and grandstream network switches

A post was split to a new topic: I have this exact same issue

Roon in a container/docker env. is not an officially supported situation.
Apologies if i misunderstood your screenshot.

Is your library fully analysed and identified? Size?

That has nothing to do with docker it’s standard Linux htop for performance monitoring. Shows what apps are doing what work the pcs resources. Roon is using all one core so it becomes sluggish in nature. Reports by many of us, no solution in sight.

I know how htop looks, but the ssh session is gert@docker which indicates a container solution.

1 Like

Ah yes very observant I missed that. Not had my coffee yet. Still it shows the same problem lots of us are getting docker or no docker.

Havel you done a trace in to Roonserver log to see what it’s doing. When it’s happened on mine it ends up being metadatasvc updates which is doing a full library metadata trawl and update from its services.

I did use roon rock on a intel nuc for a long periode, until this starts to happen. My roon server it often not responding for 1-2 hours.
I moved my roon installation to a ubuntu server (named docker) no docker running, to se if coud find the problem.
Roon is installd with the linux script, and there is nothing else running on that server.

1 Like

I can not see any special in the roonserver_log

Do you have a way to see it?

1 Like

When it becomes slow I just tail the roonserver_log.txt file or open the log up and move to the last entries. Here I can see the activity causing the issue. Which always corresponds for me to be metadata updates. Not sure if mine has had extra logging enabled by support or not but I see it pop up.

This is the last entry i have in the log file
gert@docker:~$ tail /var/roon/RoonServer/Logs/RoonServer_log.txt
12/22 11:13:35 Debug: [89] FTMSI-B-OE qo/8A95FA66 created new req 1 for block 0 p 4294967295; active requests 1
12/22 11:13:36 Debug: [79] FTMSI-B-OE qo/B2CC8726 rid:1 interrupt requested; reason: exit
12/22 11:13:36 Debug: [71] FTMSI-B-OE qo/B2CC8726 rid:1 request ended – first block: 0 blocks read: 1129 download speed: 8486kbps response time: 46ms
12/22 11:13:36 Debug: [72] FTMSI-B got length for qo/8A95FA66; 55.6 MBytes
12/22 11:13:36 Debug: [72] FTMSI-B qo/8A95FA66 download status: FileLengthRetrieved accessTimeout:True openFiles:1 prev:(DownloadNotStarted,True,1)
12/22 11:13:36 Debug: [72] FTMSI-B-OE set min bandwidth for qo/8A95FA66 to 1973 kbps
12/22 11:13:36 Info: [72] FTMSI-B-OE qo/8A95FA66 rid:1 response took 210ms
12/22 11:13:36 Debug: [72] FTMSI-B qo/8A95FA66 download status: FirstBlockRetrieved accessTimeout:False openFiles:1 prev:(FileLengthRetrieved,True,1)
12/22 11:13:36 Info: [Worker (4)] [AudioQuest] [zoneplayer] Open result (Queueing): Result[Status=Success]

All 4 cores are at 100%
I have 16G ram and they are also fully used.

As far as i rember i have around 14K tacks in my database.

Do i really need a bigger server, with more hores power and more RAM?

Something else wrong there if it’s maxing 4 cores. Is the music local to the server or over network to a NAS? Is this a new installation? Wonder if it’s stuck analysing your files somehow? What happens when you stop it and restart ? Do you see a red triangle in Roons UI anywhere when using the app?

I would remove the Qobuz url as it contain your account token and could lead to someone hacking your account.

Removed

Thanks

The files are located on a NAS server.

If i reboot the computer it runs for 24 hours or so and the the problem is back

If you check in roon settings-library is it showing any activity there.

Only file that has been changed is https_last_port

Local or streaming?

Hey @Gert_Kaae_Hansen

Running Roon in a VM or Docker is not an officially supported environment. It is considered Tinkering. Roon doesn’t prevent customers from experimenting with our software in unsupported environments; however, when you do so, you also take on the ongoing support and troubleshooting for that environment.

We wanted to provide a brief explanation before moving this [thread/post] to the Tinkering section. Hopefully, other customers who may also be using your environment can help you with diagnosing and resolving your issue.

If this does not work for you, then I would recommend running Roon in an officially supported environment for the stability and support you are looking for.

Moved back to support as OP stated he’s not running it in docker further up, the pc is makes docker that’s all.

2 Likes