> It's hard to judge; but basically if there are a lot of processes
waiting
> for I/O (a 'D' state in 'top'); try cutting down the number of
concurrent
> backups. You'll have to judge for yourself what the best number for you
is.
> It may be that things work fastest when there's a certain amount of disk
> contention; but no more and no less.

Also - you need a good filesystem to handle lots (or even not so many) of
backups. I reently switched from EXT3 to EXT4 and saw on order of magnitude
(I kid you not, 10+ hours to 1) reduction in the backup time and system
load. Unfortunately, I think this introduced some problems in the RHEL5
ext4 code so I also switched from 32-bit RHEL5 to 64-bit -- that seems to
have cleared up the problems.

-Josh


-- 
--------------------------------------------------------
       Joshua Malone       Systems Administrator
     (jmalone AT nrao DOT edu)    NRAO Charlottesville
        434-296-0263         www.cv.nrao.edu
        434-249-5699 (mobile)
BOFH excuse #202:

kernel panic: write-only-memory (/dev/wom0) capacity 
exceeded.
--------------------------------------------------------

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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/