2000-09-08-18:18:03 Chris Garrigues:
> I use rsync to backup 24 scattered machines [...] in parallel.
> When this kicks off [the] lines all come to a standstill, but the
> CPUs on the backup server barely sweat. The system is a dual
> 200mhz pentium pro with 192 meg of RAM.
I believe the difference between your experience and that of Tim is
that you are running the parallel rsync towards the same server,
where Tim would be running them away from the server.
rsync has a problem for some applications, which Tim rightly cites
relative to rdist: its memory requirements on the sending side grow
comparably to the total number of files in the tree being sent. For
some applications that can be painful. In principle it seems like a
shame, I can't offhand see why the two sides couldn't run a sorted
depth-first search with total memory requirement only
O(depth*branching-factor) of the trees, rather than having the
sending side have to build up a data structure O(total files).
As cheap as hardware is these days, I'd say that shouldn't be a
frequent problem; most folks would just replace the SS2 he's using
with a cheap PC with a half-gig of RAM, and if that could only serve
a dozen or two targets with a big enough push, well, buy more of
'em, they don't cost a bundle.
But in settings where the src machine has limited resources, dumber
programs will eat less resources and so allow better parallelism.
If the pattern of changes involves only a tiny amount of change,
rsync might still beat rdist even if it has to be more serial and
less parallel. But if large amounts of the data change, sufficiently
parallel rdists will eventually be able to beat out an rsync.
-Bennett
PGP signature
