rsync - Feb 2006 - high cpu usage of rsync process - sometimes (extremely wired)

Hello,

i have two clients (c1 and c2) with 100% same hard- and software and
also two servers (s1 and s2) with 100% same hard- and software. The
servers run "rsync --daemon", the clients start rsync periodically to
syncronize a directory with them, where c1 syncs with s1 and c2 with
s2. The directories are the same on s1 and s2!

Paradoxically the CPU Usage of the rsync process on c1 uses about 50 %
CPU (as displayed in ps -aux), while rsync on c2 uses about 1 % CPU.

Servers and Clients run Red Hat Enterprise Linux 4 on i386
architecture. The Clients use a very long command line to run rsync,
because only filenames which end on .html, .gif and so on should be
synced. In all my tests, rsync didn't ever need to copy files from s1
to c1. It just had to look if there are any jobs to do.

To get completely confused, i added the "--stats" on c1: Now the rsync
process uses about 2 % CPU - mostly! In 1 of 3 cases, it eats up 50 %
CPU again! I'm getting gray hairs with this...

Any idea or suggestion against this mystic behavior?

best regards,
Sebastian Schwerdhoefer

On Tue, 7 Feb 2006, Sebastian Schwerdhoefer <sschwerdhoefer@multamedio.de>
wrote:
> Hello,
> 
> i have two clients (c1 and c2) with 100% same hard- and software and
> also two servers (s1 and s2) with 100% same hard- and software. The
> servers run "rsync --daemon", the clients start rsync
periodically to
> syncronize a directory with them, where c1 syncs with s1 and c2 with
> s2. The directories are the same on s1 and s2!
> 
> Paradoxically the CPU Usage of the rsync process on c1 uses about 50 %
> CPU (as displayed in ps -aux), while rsync on c2 uses about 1 % CPU.
My guess is that c1 is not as busy as c2 inbetween rsyncs, so the disk
cache still has a lot of what it read during the previous rsync.

If so, then c1 does not have to wait for physical disk reads and can
quickly process the list of files it receives from the server (comparing
them with local file info), resulting in high CPU usage and taking a
shorter time to complete.

Otherwise, there may be lots of physical disk I/O required, which will
cause the process to idle more, resulting in lower CPU usage and taking
a longer time to complete.

    John