Re: The Verification Treadmill

Dominic Raferd <[email protected]> Sun, 18 Feb 2024 07:10:41 +0000
Newsgroups gmane.comp.sysutils.backup.rdiff-backup.general
Message-ID <[email protected]>
On 17/02/2024 03:14, Robert Nichols wrote:
> On 2/16/24 08:44, Dominic Raferd wrote:
>> Until then, I am interested in your parallel processing approach. 
>> Presumably you start 8 parallel rdiff-backup verify sessions for 
>> datetime points -1 to -8 (and then, when they are all complete, -9 to 
>> -16, -17 to -23...)? And you run 8 in parallel because your CPU has 8 
>> cores?
>
> I have 16 cores, actually, but by experiment I found that 8 parallel 
> threads seems to be the sweet spot. I don't know how much of that is 
> unique to my system and the nature of my backups. I did have to add a 
> pre-scan of the file_statistics metadata files to look for increment 
> sizes of 1GB or greater, and limit the number of parallel checks to 1 
> if any are found. All it takes is one huge ISO file in the increments 
> to gobble up cache and make the parallel checks really slow. I haven't 
> spent much time trying to tune that adjustment, and all the 
> experimenting was done back when I had just 32GB of RAM.
>
> I let the parallel threads run independently, without waiting for 
> anything in the others. Effectively, I run the threads with the level 
> sequences:
>      {-1..-99..8}
>      {-2..-99..8}
>      {-3..-99..8}
>      ...
>      {-8..-99..8}
> and then just wait for everything to complete.
>
> The code is really nothing like that, but that is the effect. You 
> might expect the threads to get badly out of sync, but because of the 
> effects of I/O caching, whichever threads finish a step first find 
> themselves slowed down by I/O waits more than do the threads that 
> advance to a new step later. The threads tend to stay quite 
> beautifully in sync. Again, that's on my system with my backups. YMMV.
Very interesting. A while ago I set my timedicer-verify script to run 
verifications in parallel but it seemed to make everything slower not 
faster, admittedly when running on a much less powerful (and virtual) 
machine than yours, so I stripped out all that code. But I should look 
at it again (I guess I must have backups!)...