|
Re: [BackupPC-users] backuppc slow rsync speeds
2012-09-18 10:59:03
John Rouillard <rouilj-backuppc AT renesys DOT com> wrote
on 09/17/2012 02:05:28 PM:
> On Mon, Sep 17, 2012 at 12:54:35PM -0400, Timothy J Massey wrote:
> > No matter the size of the system, I seem to top out at about
50GB/hour for
> > full backups. Here is a perfectly typical example:
> >
> > Full Backup: 769.3 minutes for 675677.3MB of data. That
works out to be
> > 878MB/min, or about 15MB/s. For a system with an array
that can move
> > 200MB/s, and a network system that can move at least 70MB/s.
>
> My last full backup of a 2559463.2 MB backup ran 306.9 minutes. Which
> if I am doing my math right is 138MB/s. This was overlapping in i/o
> with 9 other backups in various backup stages.
Woo. I like that. Now let's see why is
yours different!
> My backup drive is a 1U linux box exporting its disks as an isci
> system running raid 5 iirc over gig-E. LSI hardware raid with bbu
> write cache I think.
So this "backup drive" server is simply
the iSCSI target that provides the storage used by BackupPC running on
a different system? Or is the "backup drive" the client
of the backup process?
> 4 drive JBOD/raid0, raid 1/0, raid 5, raid 6? I'll assume raid 5.
All of that was clearly outlined at the top of the
e-mail: 4 x 2TB Seagate SATA drives in RAID-5 (using md, which I''m
not sure I stated originally).
> > My load average is 2, and you can see those two processes: two
instances
> > of BackupPC_dump. *Each* of them are using 100% of the
CPU given to them,
> > but they're both using the *same* CPU (core), which is why I
have 50%
> > idle!
>
> Can you check that with the f J(IIRC) option. I don't see the P column
> in there that would tell us what cpu they are running on.
Certainly!
Thank you very much for your suggestion. It
seems I might have been wrong: my system has not two cores, but two
*hyperthreaded* cores--four total! So, the 50% response makes sense
for two process: they're both consuming 100% of a single hyperthread.
Assuming that the Linux scheduler is properly handling the HT cores
(and I imagine it is... :) ), then I truly am using 100% of each
of the two separate cores.
That's fairly bad news for me, then. These are
embedded-style motherboards, and upgrading to a >3GHz Xeon processor
is not an option... :(
I'm going to turn off compression and see what type
of results I get. Unfortunately, it might take a week to find out:
it'll be like doing the backup for the first time again, and it took
a week (6.97 days, to be exact) the first time...
> Primary backuppc server at the moment is a server
providing file
> storage services: 24 core 48G memory (1600 MHz). But I had much the
> same numbers running on a 4 core, 32 GB (or maybe 16) machine with
an
> attached SCSI disk array raid 6 with 14 or 15 spindles (Dell
> MD1000). Disk is isci using ext4 noatime.
I'm not sure what this means. You have a 24-core
(what family and MHz?) system with 48GB of RAM. This machine is attached
via iSCSI using an unknown number of unknown interfaces to an unknown storage
unit (it can't be that 1U machine you mentioned earlier, could it? How
many drives can you have in a 1U unit?) with an unknown number of drives
of an unknown speed and interface. This "cluster" of systems
is backing up several client systems over an unknown number of GigE interfaces,
including the system you listed earlier: 2.5TB of data in a full
backup that takes 307 minutes.
> Backuppc is configured with cached checksums.
OK. What about compression?
> Local clients (we also back up systems over the
WAN) are connected
> over Gig-E.
How many GigE?
> When you see high cpu can you use strace to see what you have for
i/o
> reads/writes? Also have you tried setting this up with a
> non-compressed pool as an experiment to see if compression is what
is
> killing you.
That's my next step. When I upgraded from my
old VIA-based servers, I (accidentally) left compression on, and thought
the new, dual-core, faster and more efficient processor would be OK with
this. That may have been my biggest mistake. (Honestly, I've
already found other areas that make me think that my original distain for
compression might have been well-justified! :) )
I'll let you know in a week! :)
Timothy J. Massey
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________
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/
|
|
|
