Parity scan grinds server to halt

[VPS]

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

[trurl]

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.

[trurl]

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.

[VPS]

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.