Bacula-users

Re: [Bacula-users] bacula-fd slow? [was: Half-speed backup problem]

2010-07-22 10:49:51
Subject: Re: [Bacula-users] bacula-fd slow? [was: Half-speed backup problem]
From: Martin Simmons <martin AT lispworks DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Thu, 22 Jul 2010 15:46:19 +0100
>>>>> On Thu, 22 Jul 2010 14:43:53 +0100, Rory Campbell-Lange said:
> 
> On 22/07/10, John Drescher (drescherjm AT gmail DOT com) wrote:
> > On Thu, Jul 22, 2010 at 7:07 AM, Rory Campbell-Lange
> > > I am now using a spool to see what is happening for the locally attached
> > > Coraid storage. The locally attached storage runs at a (contended) write
> > > of 77MB/s and read of over 100MB/s as confirmed by the tool ddt.
> > >
> > > So I now have a Full backup running off local attached storage (Coraid,
> > > ext3) to fully local storage (HW RAID with BBU, xfs). However bconsole's
> > > "status client" still shows activity at around 20-30MB/s
> > > (Bytes/sec=24,363,733) with bacula-fd reading off the target at around
> > > 20-30MB/s to make a local 250GB file. Incidentally, ?bacula-sd
> > > periodically writes to tape at ~ 100MB/s.
> ...
> > > Is there a problem with bacula-fd?
> > >
> > Have you disabled software compression in your fileset? Also random
> > filesystem performance even on a raid is not great. While you may be
> > able to read 500MB/s sequential data if the files needed to backup are
> > not physically ordered sequentially the rate will greatly reduce. Are
> > you doing a Full Backup? Is your spool on a different raid than the
> > source data? If the spool is on the same raid this will cause further
> > reduced performance because it will be causing more seeks again and
> > reducing the large sequential operations.
> 
> I have disabled software compression and the backup is a Full backup as
> noted above.  The spool is local, the file system being backed up is on
> a Coraid (ethernet-attached) file system.
> 
> Your point about non-sequential file access is a good one. Nevertheless
> 20MB/s is very poor performance. 

You could try using tar or cpio on large tree of files to get a measure of how
fast data can be read from the filesystem and written to the spool.

__Martin

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>