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

 

Drives:

SSD: PNY CS900 480 GB (Cache)

HDD: 4 x WD80EMAZ 8TB

HDD: 3 x WD80EZAZ 8TB

with two of these as parity.

 

Docker Containers:

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

 

Symptoms:

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.

 

Reasons:

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!

 

 

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

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 January 6, 20197 yr by Trunkton

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 January 8, 20197 yr by Henning

I needed t o move the 'system' partition manually to the cache too but no luck with that.

 

So here is a diagnostics file:

unraid-diagnostics-20190111-1314.zip

 

Would be really glad if someone would have a look. 😁

here is another one unraid-diagnostics-20190120-1435.zip

It was taken when this happened:

 

Sadly thats thats no exception but rather the rule when writing to the unraid server.

 

Any ideas?

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.

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 January 21, 20197 yr by Henning

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.

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 January 21, 20197 yr by nuhll