My network is 2.5Gb on both ends, the array isn't doing much of anything else, the harddisks are all able to write like 200MB/s.

 

Achieved speed: 40MB/s, and it's also fluctuating quite a bit between 30 and 50 or so. The CPU on the server is not pinned, not even on a single core. There is enough free memory, not that it should matter. It's definitely writing directly to the array, not through cache. The file I'm writing is one giant file.

 

Given all this, wouldn't you say it should pretty much hit the HDD or NIC bottleneck (whichever is lower)? Apparently it doesn't do that, but I also can't figure out what's holding it back.

unraid-diagnostics-20241207-0340.zip

Whare share are you writing to?

There's a parity check going on.

Yeah, laterly I noticed the parity check. But that's not really explaining the whole story.

 

You see, in most systems, a background process is truly in the background, meaning foreground tasks *always* get priority over them. I feel parity check oughta be the same: background priority, yielding for *every* other I/O activity. I believe most OS'es have something like this going on for when they decide to do a big heavy I/O task automatically in the background.

Edited December 22, 20241 yr by thany

The parity check has never run as a background process and has always badly degraded performance of other read/write operations while it was running.  This was one of the reasons I developed the Parity Check Tuning plugin so parity operations could be restricted to running in increments outside prime time to improve users perceived performance in daily use.