rsync - Jun 2004 - [Bug 1463] New: poor performance with large block size

https://bugzilla.samba.org/show_bug.cgi?id=1463

           Summary: poor performance with large block size
           Product: rsync
           Version: 2.6.2
          Platform: x86
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: wmatthews@sepaton.com
         QAContact: rsync-qa@samba.org


I have a 29Gig file that is the previous version of a file and a 1.3 Gig 
incremental backup of the file. I did the transfer with no block size option 
and it takes about 6 minutes (GigEthernet). I used --block-size = 90k and it 
took about 6 minutes. I used --block-size=182000 (close to the square root of 
29 Gig) and it only completed ~50 Meg of transfer of the 1.3 Gig in a couple of 
hours.

Chris Shoemaker suggests this is a problem with the sliding window being a 
fixed size of 256k and that the block size will not allow multiple blocks in 
the window size. 

Operating system is Redhat 9.1 for both systems. Both systems have the 2.6.2 
with only 1 patch and it is the one Wayne provided for --bwlimit being bi-modal

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

On Wed, Jun 16, 2004 at 06:21:15AM -0700, samba-bugs@samba.org
wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=1463
> 
>            Summary: poor performance with large block size
>            Product: rsync
>            Version: 2.6.2
>           Platform: x86
>         OS/Version: other
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: core
>         AssignedTo: wayned@samba.org
>         ReportedBy: wmatthews@sepaton.com
>          QAContact: rsync-qa@samba.org
> 
> 
> I have a 29Gig file that is the previous version of a file and a 1.3 Gig 
> incremental backup of the file. I did the transfer with no block size
option
> and it takes about 6 minutes (GigEthernet). I used --block-size = 90k and
it
> took about 6 minutes. I used --block-size=182000 (close to the square root
of
> 29 Gig) and it only completed ~50 Meg of transfer of the 1.3 Gig in a
couple of
> hours.
> 
> Chris Shoemaker suggests this is a problem with the sliding window being a 
> fixed size of 256k and that the block size will not allow multiple blocks
in
> the window size. 
Er, that suggestion sounds WAY too intelligent to have come from me.  :-)
Seriously, that was Craig Barratt.
-chris
> 
> Operating system is Redhat 9.1 for both systems. Both systems have the
2.6.2
> with only 1 patch and it is the one Wayne provided for --bwlimit being
bi-modal
> 
> -- 
> Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug, or are watching the QA contact.
> -- 
> To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

I apologize to Craig. Chris is correct.
I had been reading so many of Chris's highly intelligent e-mails that for
some reason my brain
ascribed the comment to Chris. 

But, the comment seems to have been right on. I have re-run the experiment with
block sizes as small as 3000 (yes it took a long time to complete) all the way
up to block sizes of 100000 with it working in reasonable times. But, when the
block size approaches 170,000 or so, the performance degrades exponentially.

I understand that I am testing at the very fringes of what we should expect
rsync to do. File sizes of 25Gig and 55Gig are beyond what was originally
envisioned (based on 64k hash buckets and a sliding window of 256k).

I am very impressed that rsync is functional at these file sizes. The developers
are doing a great job.

wally

-----Original Message-----
From: Chris Shoemaker [mailto:c.shoemaker@cox.net]
Sent: Wednesday, June 16, 2004 1:45 PM
To: samba-bugs@samba.org
Cc: rsync-qa@samba.org
Subject: Re: [Bug 1463] New: poor performance with large block size


On Wed, Jun 16, 2004 at 06:21:15AM -0700, samba-bugs@samba.org
wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=1463
> 
>            Summary: poor performance with large block size
>            Product: rsync
>            Version: 2.6.2
>           Platform: x86
>         OS/Version: other
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: core
>         AssignedTo: wayned@samba.org
>         ReportedBy: wmatthews@sepaton.com
>          QAContact: rsync-qa@samba.org
> 
> 
> I have a 29Gig file that is the previous version of a file and a 1.3 Gig 
> incremental backup of the file. I did the transfer with no block size
option
> and it takes about 6 minutes (GigEthernet). I used --block-size = 90k and
it
> took about 6 minutes. I used --block-size=182000 (close to the square root
of
> 29 Gig) and it only completed ~50 Meg of transfer of the 1.3 Gig in a
couple of
> hours.
> 
> Chris Shoemaker suggests this is a problem with the sliding window being a 
> fixed size of 256k and that the block size will not allow multiple blocks
in
> the window size. 
Er, that suggestion sounds WAY too intelligent to have come from me.  :-)
Seriously, that was Craig Barratt.
-chris
> 
> Operating system is Redhat 9.1 for both systems. Both systems have the
2.6.2
> with only 1 patch and it is the one Wayne provided for --bwlimit being
bi-modal
> 
> -- 
> Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug, or are watching the QA contact.
> -- 
> To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

I applied your patch and it has resolved the problem.

Thanks Craig

-----Original Message-----
From: Craig Barratt [mailto:cbarratt@users.sourceforge.net]
Sent: Thursday, June 17, 2004 11:48 PM
To: Wallace Matthews
Cc: samba-bugs@samba.org; rsync-qa@samba.org
Subject: Re: [Bug 1463] New: poor performance with large block size 


Wally writes:
> I apologize to Craig. Chris is correct.
No problem.
> I had been reading so many of Chris's highly intelligent e-mails...
Same here.
> But, the comment seems to have been right on. I have re-run the
> experiment with block sizes as small as 3000 (yes it took a long
> time to complete) all the way up to block sizes of 100000 with it
> working in reasonable times. But, when the block size approaches
> 170,000 or so, the performance degrades exponentially.
>
> I understand that I am testing at the very fringes of what we should
> expect rsync to do. File sizes of 25Gig and 55Gig are beyond what was
> originally envisioned (based on 64k hash buckets and a sliding window
> of 256k).
Here's a patch to try.  It basically ensures that the window is
at least 16 times the block size.  Before I'd endorse this patch
for CVS we need to make sure there aren't cases where map_ptr is
called with a much bigger length, making the 16x a bit excessive.

Perhaps I would be tempted to repeat the previous check that the
window start plus the window size doesn't exceed the file length,
although it must be at least offset + len - window_start as in
the original code.

In any case, I'd be curious if this fixes the problem.

Craig

--- rsync-2.6.2/fileio.c        Sun Jan  4 19:57:15 2004
+++ ../rsync-2.6.2/fileio.c     Thu Jun 17 19:33:26 2004
@@ -193,8 +193,8 @@
        if (window_start + window_size > map->file_size) {
                window_size = map->file_size - window_start;
        }
-       if (offset + len > window_start + window_size) {
-               window_size = (offset+len) - window_start;
+       if (offset + 16 * len > window_start + window_size) {
+               window_size = (offset + 16 * len) - window_start;
        }
 
        /* make sure we have allocated enough memory for the window */