Noticeably lower parity check speed on last run. Any ideas?

[-Daedalus]

Hi all,

 

So my most recent parity check just finished, and the speeds (as shown below) are noticeably lower than what has been an otherwise pretty consistent trend.

 

Box is currently on 6.3.3, and I'm pretty sure the check before this was also 6.3.3, but I'm not 100%, as, IIRC, it came out right around the time as the check would have run. Perhaps this can be checked, I'm not sure. Diagnostics attached in any case.

 

The only thing that I know for certain has changed in that time is that I now have a CentOS VM going, hosting an ARK server. I can't imagine cache pool drives having any affect on the array drives, but maybe the RAM usage plays a part? Went from about 40% usage to 90% (of 16GB). ARK is an absolute hog.

 

I don't really mind. It's not like a little over a day vs. 21 hours actually makes much difference, it just seems odd to have this much of a change all of a sudden.

 

Anyone any ideas?

 

Thanks!

server-diagnostics-20170502-1222.zip

[Frank1940]

Best guess would be that there was some other disk activity going on while the parity check was running.  (Remember that speed of the parity check is  determined by the speed of the disks in the array.)  With your check taking more than a day, either a 'user' accessed the array or a schedule event occurred during that time.  Perhaps, both occurred...

 

If you are really concerned, rerun the check and made sure that nothing happens during that time.  (That's an 'issue' with large capacity array drives as it no longer becomes possible to schedule the parity check during a portion of the day when the array is likely to be inactive.) 

[-Daedalus]

Oh there absolutely was. I was watching movies off of the array, writing to the cache pool, and a couple of other things, but this isn't unusual and was almost-certainly happening with the last checks as well. (I work from home, and store everything on the NAS).