I've noticed quite a few threads discussing the horrendous speed drop
when using GZIP, and I've seen it myself.

disk->disk backups run at about 6mbyte/sec, but only 400k/sec when using GZIP1.
Is bacula-fd reporting compressed output speed?  

Best guess is the file readahead is failing when we're using gzip,
meaning we read, compress, then begin reading again.  Ideally, that
second read should be 'free', because the kernel has
already requested it.  In this case, it seems to be taking far too long.

One possibility may be forking, reading in one and compressing/writing
in the other.  This has two nice advantages, one, lots of dual CPU
systems and two even on single-processor systems we have constant
banging on the IO even while the other is CPU bound.

Something is very wrong, though, because gzip -6 on the same machine
pulls around
5.8meg/sec.  32k buffers, no forking.   Output (on mailboxes and
logfiles) is around 1.4meg/second.

--Dan


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to