Speed problem

[jw schultz]

On Tue, Nov 12, 2002 at 07:27:12AM +0100, uwp at dicke-aersche.de wrote:
> On Mon, 11 Nov 2002, jw schultz wrote:
> 
> > What is the CPU load of rsync on the receiver?  That is
> > important.
> 
> I'll check that.
> 
> >> The disks have an upper limit of 52 MB/s (ext2) respectively
> >> 45 MB/s (ext3). It's an IDE RAID with 12 WD disks.
> >
> > You are giving us dribs and drabs.  Now you mention ext2
> > and ext3 filesystems.  Since i'm not aware of any other OS
> > that uses them i'll assume you are running some form of
> > Linux.
> 
> Yes, I'm running Linux. I just wanted to show you that the system
> is in fact almost sleeping by doing the rsync operation. It's
> reacting fast during the transfer. The machine still stays fast
> only the rsync drops.
> 
> > need to know what kernel(s) and patches you are running,
> > what network cards, how much memory, and things from vmstat,
> > iostat, netstat.
> 
> I'll check that too. The kernel is a standard-kernel from debian.

That doesn't tell me anything.  I doubt it would be
considered informative to someone who uses debian either.

uname -mr would be a start if it gets to that.

> 
> > Frankly, the fact that it starts out running with near
> > expected performance but proceedes to decay sounds less
> > like a rsync problem and more like something interesting
> > happening in the kernel.
> 
> But why does it only happen with rsync ?

You are syncing files larger than 60GB each.  Each file is
going to be spread over large areas of the disks.  I doubt
the files are much fragmented.

If the files are completely changed or new rsync would copy
them much like any other tool.

If however those files have much of their content identified
as unchanged, rsync will be merging the changed parts with
the unchanged parts into the temporary file.  It is unlikely
that the a block of the copy will be anywhere near the
coresponding block of the original.  This means you will be
copying parts of 60+GB files from one part of the disk to
another.  I'll bet your disks are seeking like mad.

What sort of performance do you get doing a simple cp or dd
of one of these files into a copy on the same filesystem?

I do have one idea that might help.  This is purely
speculative and i haven't tried it myself but if you bump
the MAX_MAP_SIZE defined in rsync.h to a larger value rsync
should read in larger chunks reducing the frequeny with
which it will need to alternate between writing and reading.
Currently it is set to 256KB.  You could try bumping it to 2
or 4MB.  That will increase the memory footprint a little
but that shouldn't be a problem in your case.  This may
cause rsync to read considerably more than it needs but
reading data tends to be far less time consuming than
seeking.  I don't think it will break rsync.  It is possible
that it will have little or no effect or even make things
worse but i strongly suspect it will make things much better
if i have sussed your case.

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

		Remember Cernan and Schmitt