Henning Posted January 6, 2019 Share Posted January 6, 2019 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! Quote Link to comment
JimL Posted January 6, 2019 Share Posted January 6, 2019 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 Quote Link to comment
Trunkton Posted January 6, 2019 Share Posted January 6, 2019 (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 January 6, 2019 by Trunkton Quote Link to comment
Henning Posted January 8, 2019 Author Share Posted January 8, 2019 (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 January 8, 2019 by Henning Quote Link to comment
Henning Posted January 11, 2019 Author Share Posted January 11, 2019 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. 😁 Quote Link to comment
Henning Posted January 20, 2019 Author Share Posted January 20, 2019 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? Quote Link to comment
JorgeB Posted January 20, 2019 Share Posted January 20, 2019 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. Quote Link to comment
Henning Posted January 21, 2019 Author Share Posted January 21, 2019 (edited) 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, 2019 by Henning Quote Link to comment
JorgeB Posted January 21, 2019 Share Posted January 21, 2019 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. Quote Link to comment
NewDisplayName Posted January 21, 2019 Share Posted January 21, 2019 (edited) 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, 2019 by nuhll Quote Link to comment
Recommended Posts
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.