November 23, 20169 yr I recently just replaced my parity drive and I am currently doing a parity sync. I am noticing that the sync speed is varying greatly. It will sync at about 8 MB/s for several hours then jump to about 40 MB/s, then back down again. At first I thought maybe I had a bad connection on one of my drives, but after looking at the system stats graph for disk activity I think it has something to do with another process running. I noticed that the speed decreases have happened right around 5:00 AM, which is shortly after some nightly scripts run. One of the scripts simply shuts down all my docker containers, backs them up, and turns them back on. I then started to look at processes and open files. I noticed that I have maybe 20 or so files that are opened with the process "b2sum" which i understand is blake2 hashing. The files that are being used by this process are *.part files that may have been modified after a container restart of transmission. Could this be causing the extreme slowness of the parity sync? Is there anyway to kill these and prevent them from starting back up? Every time i try to kill one process it just pops back up with the same file. EDIT: doing a killall to bunker and b2sum did the trick. Now cruising at 40 MB/s nearly instantly after those processes were stopped. If anyone else runs into a similar parity sync speed issue, be sure to check what processes are running! Also, if you are using the Dyanmix File Integrity plugin, then be sure to setup your exclusions (in my case the *.part files)
Archived
This topic is now archived and is closed to further replies.