|
Mike said:
> John said:
> > What kind of CPU load are you seeing? rsync is more CPU intensive than
> > most other replication methods, which is how it gains its bandwidth
> > efficiency.
>
> CPU Load? What CPU Load?
How many files are you syncing up - a whole filesystem, or just a few
key files? From you answer, I assume you are not seeing a significant
CPU load.
The reason I ask is that all the docs I have read about rsync suggest
that the CPU load can be an issue in some cases. For example, from
http://sunsite.dk/SunSITE/guides/rsync/rsync-mirroring02.html:
"2.7: Advanced installation
If you are running a busy site, it is worth to consider the impact of
rsync daemon. The daemon make a high impact on the server in terms of
both CPU and disk I/O. The disk I/O is similar to running a ftp server,
but the CPU usage is higher. The CPU usage is due to the nature of rsync,
where it will have to open every file and calculate checksums. In most
cases, however, it only has to open and calculate checksums if it decides
that a sync is necessary. So it will in fact use very little CPU to do a
mirror run if no files (or not many files) have changed."
Also, from http://www.humbug.org.au/talks/rsync/:
"Introduction
rsync is a replacement for mirror and rcp. It copies files and
directories between two hosts, utilising a minimum amount of bandwidth
by sending only the data that it needs to send to synchronise the
source and destination.
It calculates a block-by-block checksum of the source tree, sending
these checksums over a network link, where a second rsync compares them
against a list of checksums calculated at the destination. Only portions
of the source tree that have different checksums are sent across the link,
saving bandwidth at the cost of some CPU time."
And from http://www.openoffice.org/FAQs/mirrors_faq.html:
"Do you support rsync? Why not?
We do not currently support rsync. We are concerned about the impact to
CPU and disk usage involved in supporting rsync, and until we can get a
chance to benchmark HTTP vs rsync in terms of system load, OpenOffice.org
will stick with HTTP. We are actively pursuing this benchmarking effort,
and will post an update to the OpenOffice.org discuss list when it's
completed."
--
John Cronin
mailto: `echo NjsOc3@xxxxxxxxxxx | sed 's/[NOSPAM]//g'`
|
