High CPU on multiple syncs on Win2K

bart.coninckx at watco.be bart.coninckx at watco.be
Fri Aug 23 10:38:00 EST 2002





>There are so many factors i couldn't even start.  It is
>possible changing OS for the server would help as linux has
>historically been more efficient at disk I/O in the general
>case but as i haven't done comparisons and have no NT or
>W2K servers to even try.  I recall there being a patch to
>preserve ACLs in NT-NT rsync so there may be a functional
>benefit to sticking with an NT server (yuck!).

ACLs are not important to us. Mind you, we sync Netware data and
permissions there aren't synced anyway.
BTW: my first choice would be Linux as well, but I'm the only one able to
support it, so there's get to be a real functional motive to "upgrade" ;-)

>Some things that would help in evaluation would be the
>rsync command-line and the disk configuration (are you running
>RAID, what level and HW vs. SW, etc), approximate file counts
>and size, and it also might help if we knew if the overloaded
>server were low powered.

this is the command line of the server:
rsync --daemon --config=rsyncd.conf

client:
rsync -rtv --delete --modify-window=2 --stats /cygdrive/r/
bee2bs01::d/backup/servername/data/

We're using hardware RAID 5.

>As a start i would check to be sure that you aren't using
>the --checksum option unnecessarily.

Nope, we use the default...

>That was apparently the
>problem the last time someone reported excessive load.
>Also, don't run software RAID-5.

No, we indeed prefer hardware RAID. We use a SCSI to ATA RAID configuration
(a device with a SCSI connector, but with IDE disks in it), but this should
not influence CPU performance, since the machine sees natice SCSI.

>The other thing that would be worth doing is to manage the
>load better by reducing the number of simultaneous
>connections.

True, but we have a limited timeframe (about 10 hours), to sync everything.
It could well be that Rsync manages to do an avarage site in less than 2
hours, but we don't know yet. There are a lot of variables there: what is
changed in data on a particular day on a particular site, how fast is the
WAN link, ... Since the clients are scattered, it's also hard to
orchestrate a steady scheme. This would have been a lot easier in a pull
configuration, but as I mentionned, for some reason the Rsync service
(daemon) won't work with Netware mappings.

>Leave off the disclaimer.  When you post to the list there
>is no confidentiality and it wastes electrons :)

Sorry, auto signature, you know how it goes ...


Thx for the reply!


Bart






More information about the rsync mailing list