I've noticed that if I need to rebuild (or to some extend just check) parity, my docker containers which are separate from the array and are on the cache disks become very contended and I am wondering if there's a simple explanation as to why?

 

My array takes around 24 straight hours at full speed to rebuild parity, and I also have two 1TB SSDs as cache disks on btrfs. It seems that if I begin a parity operation, access to all these containers also slows to a crawl, even containers that I would expect to be responsive during this. For example one of the containers is Pi-hole, and my DNS queries will take multiple seconds to come back, sometimes even timing out, which is extremely noticeable on the network.

 

CPU stats during the operation seem fine, I have 6 cores 12 threads, and only 3 cores seem to be in use during the operation, memory also seems okay, but IOWait is high. Would love to hear if this is "normal" for Unraid or if something may be up.

Edited December 21, 20205 yr by Pet0r

Operations on the server can be a bit slower when the Parity check happens, but it should not be as bad as what you describe.

 

@Pet0r are you sure that all your appdata if on your SSDs and that some is not on you Array ?

You can look at that on you Share tab with Compute All.

 

You could also share your diagnostics (Tools / Diagnostic) for a periode where you had this issue.

The experienced user could have a look.

I checked as you suggested and nothing was on the array, only the cache disks, however I did notice that Pi-hole was using /mnt/user/appdata/pihole for its data directory, I am wondering if that was having an effect so I have changed it to /mnt/cache/appdata/pihole so it goes directly to the cache (I never intend to be in a situation where I do not have cache disks in the system) - maybe that is the problem?

So unless the issue takes a long time to happen (I normally kick off parity operations before I go to bed and then by the time I wake up DNS is slow/broken), that might have actually fixed the problem. IOWait is no longer high at all and DNS responses are quick, and parity has been rebuilding for the last 45+ minutes or so.

 

I wonder if when things are rebuilding, access to /mnt/user/ even if the data you want resides on the cache, can be under heavy contention, and pointing the docker mounts directly to /mnt/cache/ bypasses that... but maybe it's just a coincidence.

Edited December 21, 20205 yr by Pet0r