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
|