John Rouillard <rouilj-backu...@renesys.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


 
Out of the Box Solutions, Inc. 
Creative IT Solutions Made Simple!
http://www.OutOfTheBoxSolutions.com
tmas...@obscorp.com 
 
22108 Harper Ave.
St. Clair Shores, MI 48080
Office: (800)750-4OBS (4627)
Cell: (586)945-8796 
------------------------------------------------------------------------------
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@lists.sourceforge.net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to