Holger Parplies wrote:
> first of all, where are you seeing these figures, and what are you
measuring?
Rather than try to convince you of my competence, I will offer up these
benchmarks for the exact same endpoint machines and file (a 2 gigabyte
uncompressable *.avi file that did NOT exist on the target):
Unix rsync->Unix rsync: 60MB/s
Windows SMB->Unix smbclient: 65MB/s
Windows rsyncd->Unix rsync: 5MB/s
Windows rsyncd->BackupPC_dump: 5MB/s
As you can see, something is now clearly wrong with the windows rsyncd
source. I confirmed this by profiling actual rsync in Unix and saw that
77% of its time was spent waiting for data (which mirrors exactly what
File::RsyncP::pollsys was doing, wasting 77% of its time waiting for
data). So the problem isn't BackupPC, it's windows rsyncd.
I initially used cygwin rsync; for the above test, I switched it out for
DeltaCopy's rsync. BOTH VERSIONS had this kind of crappy speed. Both
versions showed hardly any CPU or filesystem usage; they just simply run
slowly for a reason I can't figure out. The network isn't slow (gigabit
ethernet), the checksums aren't taking a long time (it's a brand new
file that doesn't exist on the target so there's nothing to checksum),
the hard drive isn't slow (raid-0 SATA stripe capable of 130GB/s read
speeds) -- it just simply serves data really really slowly.
I can't believe this is an isolated incident. Other people have got to
be seeing this. Other than cygwin and DeltaCopy, is there any specific
version of rsyncd I should be using? Any flags I can set in BackupPC
that can improve speed?
> The primary purpose of the rsync protocol is to save network
bandwidth. So if,
> for example, you are transferring only one tenth the amount of data
for a full
> backup, and that takes the same time as with SMB, your network
throughput will
These are not incrementals, but full backups, and the speed as
previously mentioned is 1/10th that of SMB. SMB backups are quite fast
on this same infrastructure (around 65MB/s) but I can't use SMB because
of XP/Vista/Win7 permission problems.
> I believe Craig is researching other alternatives (a fuse FS to handle
> compression and deduplication, so BackupPC could, in fact, use native
rsync).
I hope that doesn't become mandatory, because that would limit BackupPC
to Unix versions that support FUSE (not all do).
--
Jim Leonard (trixter AT oldskool DOT org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
