Sorry I miss spoke in the original post.  I'm backing up a server which has 
24x2.6ghz cpus and is barely using any of them.  I bacula server is much 
smaller, only 4 cpus.  It looks like bacula has a single threaded compress 
engine which appears to bottle neck the whole process.  For most backup jobs 
this isn't a problem but for the size of these backups I need speed over backup 
size on disk.

Thanks,
Derek

On Jul 1, 2010, at 11:55 , Gavin McCullagh wrote:

> On Thu, 01 Jul 2010, Derek Harkness wrote:
> 
>> I've seen a very significant slow in backup speed by enabling gzip
>> compress, 32MB/s (without gzip) vs 4MB/s  (with gzip).  The server I'm
>> backing up has lots of CPU 24x2.6ghz so the compression time shouldn't be
>> a huge factor.  Is this normal for bacula or is there an optimization I'm
>> missing.
> 
> As I understand it, the compression is done on the client (ie the file
> daemon), not the server, so it's the CPU speed of the client you need to
> consider, not that of the server.  Is the CPU maxed out on the client
> during the backup?
> 
> Gavin
> 
> 
> ------------------------------------------------------------------------------
> 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
> 
> 


------------------------------------------------------------------------------
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