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