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@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
