>>>>> "JG" == John Goerzen <[EMAIL PROTECTED]> writes:
Hi John! JG> On Wed, Aug 16, 2006 at 05:32:28PM +0200, Anders Boström wrote: >> We have a problem with very long backup-times of our file-server. JG> I suspect this is not a Debian-specific problem and also probably not a JG> bug. I would suggest that you post on the bacula-user mailing list. JG> This is likely a configuration issue that could be related to anything JG> such as the storage of filenames in the database, network buffer size, JG> etc. Yes, I agree that this probably isn't a debian specific problem. However, I'm quite sure we can rule out the backup-server as ethereal tells me that the backup-server responds directly to all packets from the file-server, but the file-server sometimes don't sent a single packet for 400 ms. JG> I should also say that the suggestion that software compression wouldn't JG> slow things down is incorrect. It certainly will, in any system. The JG> only possible time that it won't is if the CPU is so much faster than JG> the data pathways that it won't slow it down, but you don't know that JG> from the figures you posted. I agree that software compression should slow down the backup unless you are communication limited. And we are not communication limited in this case. BUT we are not CPU-limited either (one CPU 100% idle during backup, the other mostly >90% in IO-wait). We should *only* be disc IO-limited, and even the fastest case, local tar, is very slow. At only 1162 kbyte/s (bacula-fd without SW-compression), the SW-compression should not slow down the backup more than a few percent. As a comparison, 'gzip -6' (as should be used according to the manual) on this machine sustain ~18 Mbyte/s. Also, why is bacula-fd without SW-compression much slower than tar? But, as you suggested, I should try the bacula-user mailing list as this probably isn't debian-specific. / Anders
