Speed problem

[jw schultz]

On Wed, Nov 13, 2002 at 10:02:34AM +0100, uwp at dicke-aersche.de wrote:
> On Tue, 12 Nov 2002, Wayne Davison wrote:
> 
> > On Tue, Nov 12, 2002 at 11:30:28PM +0100, uwp at dicke-aersche.de wrote:
> > > And why it tries to get 100% CPU even though there's nothing to do ?
> >
> > What do you mean "nothing to do"?  Rsync is creating the new version of
> > a changed file which is done both by transferring data over the network
> > and by copying matching data from the existing version of the file.
> > Just because nothing is being transferred over the link doesn't mean
> > nothing is going on.  Or is there some other problem that I missed in
> > this discussion?
> 
> When recovery on the receiving side started, there's almost nothing to
> do for the sending side, it just has to wait until the partial copy
> is ready to get data appended. In this time rsync on the sending side eats
> 95% of CPU time. I would say, that this is not the right behaviour, the
> rsync process on the sending side should idle in this time.

Recovery is the wrong word.  If you specified --partial and
rsync was interrupted the receiver will delete the original
file replacing it with the partially transfered file.  There
is no recognition by rsync that the receiver has a partial
file, only that the file is out of sync with the sender.

While the receiver bears the brunt of the CPU work the
sender is hardly idle.  Aside from generating the initial
filelist it must generate and transmit block checksums for
each file that the receiver identifies as having changed.
Any blocks the receiver identifies as having changed the
sender will have to re-read and send.

You may want to read the whitepaper.

I'd suggest running with -vvvv (that's four "v"s) and
watch the process live.  Or run strace on the sending
process.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt