February 17, 20197 yr After searching and trying some of the fixes I found I am not able to fix this issue. Once a parity scan has been started things like browsing plex, starting a movie and Sabnzbd downloads are painfully slow or stop entirely. Sabnzbd for example usually sustains 100mbs slow to around 200kbs or stop. Things I have checked or changed: Confirmed all docker files and VM are on the cache drive Updated the BIOS and firmware to latest Shutdown all dockers and VM then checked Sabnzbd performance Looked at the syslog: only error that stands out from my searches is the kernel call trace that appears right after starting the parity scan and is why I updated the bios as mentioned as possible fix. Sabnzbd downloads and unpacks to cache drive. Radarr/Sonarr move to array once completed. CPU is always at a reasonable usage likely no more that 50% Peak ram usage is around 60% and mostly due to a ram disk for Plex transcodes My specs are: Unriad 6.6.6 M/B: Supermicro - X10SRL-F CPU: Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz Memory: 64 GB Multi-bit ECC lsi 9211-8i IT mode SuperMicro 2U chassis with non expander A type SFF-8087. This is just used for the array. Cache drives are connected to MB 6gb ports Performance of system is excellent when parity scan is inactive Dual parity: 2 WD 8TB Red Arrary: 4 WD 8TB Red xfs Cach pool: 2 Intel S3500 800GB btrfs Unassigned: 1 WD 6TB Red Running Dockers: Plex Radarr Sonarr Lidarr Sabnzbd Nextcloud Mariadb Ombi Tautulli Letsencrypt/nginx VM: 1 Win 10 running Plex Plugins: ca.backup2.plg - 2019.01.13 ca.cleanup.appdata.plg - 2019.01.13 ca.update.applications.plg - 2019.01.31 community.applications.plg - 2019.02.16a dynamix.ssd.trim.plg - 2017.04.23a dynamix.system.buttons.plg - 2018.09.08 dynamix.system.stats.plg - 2018.08.29a fix.common.problems.plg - 2019.02.16a NerdPack.plg - 2019.01.25 nut.plg - 2019.02.03 statistics.sender.plg - 2017.09.22 unassigned.devices.plg - 2019.02.12 Attached log files downloaded about 8 hours after last parity scan attempt. Thanks for the help tower-diagnostics-20190217-0944.zip
February 17, 20197 yr Community Expert Parity check requires reading all the disks. Parity check and any other process trying to access those disks will be competing with each other, with the result that the disks often have to "thrash", moving the read/write heads and waiting for the disk to spin, as it seeks the sectors one process is using, then seeks the sectors the other process is using, then etc.
February 17, 20197 yr Community Expert Why are you doing a parity check anyway? Most people just schedule a parity check to run once a month. Unraid parity is realtime so should always be correct. A parity check is just intended to be an occasional test that parity is still correct.
February 17, 20197 yr Author I realize how the scan works in the sense that it has to access the drives which will slow down processes competing for the drive. If the parity check makes the server unusable by design then that is unacceptable, I however do not believe this to be the case or there would be many more posts like this and I would have run into the issue years ago. Things like Sabnzbd are on the cache drives which don't show much activity during the scan and are capable a lot of i/o yet it still grinds to a halt. This hasn't been an issue until last fall. I actually have the check scheduled to scan once every two months. However every time it scans it take somewhere around 24 hours or more to complete and as mentioned the server is pretty much useless for that time. The manual scans I have been starting have been for testing purposes.
Archived
This topic is now archived and is closed to further replies.