Seems to be working much better. I just installed it on our main servers,
the client gets,
treacy 29488 4.4 5.2 3768 3320 p5 S20:32 0:15 rsync -avz
treacy 29511 7.9 9.8 6660 6164 p5 S20:33 0:23 rsync -avz
And the server gets,
treacy 15724 9.7 6.5 5512 4132 ? S22:32 0:33 rsync --server
yep, the main thing you'll find is that as the number of files gets
really large it won't increase much. The reason this was so bad before
is that I have 256MB on samba.anu.edu.au and it wasn't till I noticed
it was using 120MB of ram to sync a 9GB disk that I realised what a
memory hog rsync was. It now uses about 12MB to do the same thing.
Which is much nicer I think, I'll see how the other archive does later on.
Do I need to get the clients to upgrade to the newest version to get the
reduced memory usage on the server?
Depends on how you use it :-)
The main memory usage was on the sending side, but if you use --delete
then it also got bad on the receiving side. The culprit was realloc(),
it was fragmenting the heap really badly. The actual amount of memory
it wants isn't that large, but realloc() was the wrong way to get it :-)
BTW, I don't know if you have heard the story, but rsync is one of the few
programs that is capable of mirroring our Bug pages, the perl stuff just
chokes! The Bug archive has -alot- of small text files.
I'm glad it's useful!
I'll be releasing a anonymous rsync package soon that you guys might
like. I'm settiing up mirrors of samba.anu.edu.au so I thought it was
about time I did a secure anonymous rsync daemon (Warren released one
a few months back, but the security wasn't quite up to scratch so I
didn't include it in the standard release).
Cheers, Andrew
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
