Jump to content

Generally pretty slow perfomance

10 posts in this topic Last Reply

Recommended Posts

Hi there!

I built my first unraid server a month ago and generally I am pretty happy with the gui, features ecosystem etc. My only downside which is a pretty big one, is that the system is extremely slow and I don't know the reason for it. So hope to find the reason for my issue with your help since I don't know exactly where to start looking.


My System:

CPU: Ryzen 2600

MB:   Gigabyte X470 AORUS Ultra Gaming

RAM: 2 x G.Skill Aegis 8GB DDR4-3000MHz

PSU: Enermax Platimax D.F. 600W

Sata/SAS Card: Dell H200



SSD: PNY CS900 480 GB (Cache)



with two of these as parity.


Docker Containers:

  • Krusader
  • jackett
  • ombi
  • plex
  • radarr
  • sonarr
  • sabnzbd
  • tautulli
  • transmission_vpn



When I started using Unraid, everything was fine. It slowed down when I began adding Docker containers to my system. Without any containers running, I am able to copy files with full speed on it (Gbit ~110 Mb/s). But when I started to start some containers the write speeds slowed down a lot. Also the performance of the docker services is lacking, for example radarr/sonarr needs 10-20 seconds to load a single page and sometimes they can't open a page at all. The performance is the worst when sabnzbd is downloading files. Write speeds to a share drop to 0 or do not respond at all. Read speed is pretty bad as well, can't open folders in Windows explorer without crashing and skimming/playing video files is also not possible.



I really have no idea.

1. First I am not sure if such a behaviour isn't normal at all and I am just wanting to much from the system but I would have thought that my hardware should be capable to download, copy and host a webserver at the same time. Am I wrong?

2. Parity Drives. The symptoms existed before I added the two parity drives so I can rule them out.

3. Cache drive. This is my biggest guess. I added the drive later in my build and maybe I configured it badly? Every share of mine is set to use the cache disk. The 'appdata' and the 'system' share are set to only use the cache so I guess they won't be moved at night. The drive is connected to the mainboard, not the SAS card.

4. BIOS setting. Is there something I should look out for?

5. ??? Do you have more ideas which could be the reason?


Thanks for your help!



Share this post

Link to post

It's not normal. Can you post a diagnostics file from when or right after the system slows down?


tools -> Diagnostics


or run "diagnostics" in ssh/terminal

Share this post

Link to post
Posted (edited)

Hi Henning,


Check this out, it sounds like the same issue that you're having: 


Am not poster here but I found it informative and ended up doing the same.

To mitigate this issue on my end what I ended up doing was building the array with cache drive SSD then going new config and removing the SSD setting all options on all shares beforehand to use cache=no and run mover before going new config. Now, Docker and VM's run completely independent of the array to preserve performance.


If/when I elect to use a cache drive it will be spinning rust not an SSD to only be used as a cache.


Hope that helps!

Edited by Trunkton

Share this post

Link to post
Posted (edited)
On 1/6/2019 at 10:51 PM, JimL said:

Can you post a diagnostics file from when or right after the system slows down?


Will definetly do but can't find the time right now for it!


On 1/6/2019 at 11:11 PM, Trunkton said:



Check this out, it sounds like the same issue that you're having...


Thank you for your answer, it hinted me in a right direction. I added the cache driver after configuring the docker files. I assumed that setting the appdata share to only use the cache disk, the next mover job would move all appdata from the array to the cache. This isn't the case. I had appdata data on different array hdds and the cache disk. I suspect that only new data got written to the cache disk.

I moved everything onto the SSD now and Plex feels way snappier now. 😘
But when I start SABnzbd the system slows down again and turns sluggish, so I will search further and come back with some diagnostics.

Edited by Henning

Share this post

Link to post
4 minutes ago, Henning said:

Any ideas?

There's read activity on disk3 at the same time you're writing to it, that will severely impact array write performance, there's also reading on disk4.

Share this post

Link to post

Thanks for the answer, 

reading activity is correct but I was under the impression that writing should go to the cache drive. 

The share I was writing too has a split level set, will this setting prevent caching? 


Edit: oh I checked the screenshot again, I was reading from the disk so I dont know exactly what was writing to the disk. 

Edited by Henning

Share this post

Link to post
1 hour ago, Henning said:

The share I was writing too has a split level set, will this setting prevent caching? 

No, as long as the share is set to use cache, try writing directly to the array with turbo write enable, and see if it's faster.

Share this post

Link to post

does it helps if you restart your docker containers?


I know some dockers take more and more resources the longer they run.. (memory leak)


I just startet using CA Backup plugin to back them every day up, and have a reason to restart them.


jackett and radarr/sonarr are known for that. 

Edited by nuhll

Share this post

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.