>>>>> "JD" == John Drescher writes: >>>>> "JG" == John Goerzen <[EMAIL PROTECTED]> writes:
JD> Are you using MD5 or SHA1 signatures? Do you have the database JD> indexed properly? No, no signatures are used. The database is indexed properly seems to be very fast. As I stated below, the backup-server is responding directly at all time, and is unloaded during backup. / Anders JG> Hello Bacula folks, JG> We received this message at the Debian bug-tracking system, and thought JG> that this is probably a more appropriate forum for it: JG> ----- Forwarded message from Anders Boström <[EMAIL PROTECTED]> ----- JG> From: Anders Boström <[EMAIL PROTECTED]> JG> Date: Wed, 16 Aug 2006 17:32:28 +0200 (CEST) JG> To: Debian Bug Tracking System <[EMAIL PROTECTED]> JG> Subject: bacula: backup is slow JG> Package: bacula JG> Version: 1.38.11-1 JG> Severity: normal JG> We have a problem with very long backup-times of our file-server. JG> The file-server is only used for NFS and is quite heavily loaded. It JG> is a Debian etch amd64 with a 2.6.16.20 kernel running on a Athlon 64 JG> X2 3800+ (dual core) with 2Gb mem and two 500 Gb discs in raid1. ext3 JG> is used as filesystem, with dir_index enabled. JG> The backup-server is also a Debian etch amd64 but with a 2.6.15.6 JG> kernel and an Athlon 64 3200+ CPU with 512 Mb mem. Both bacula-sd and JG> bacula-dir is running on the backup-server, as well as a JG> mysql-daemon. Discs are used for backup. JG> The file-server and the backup-server are connected via an GE-network JG> without loss. JG> I've done some measurements on a ~7.5 Gb directory tree with 88208 JG> files (just one user-account): JG> bacula backup without SW compression: 1 hour 45 mins 2 secs JG> bacula backup with SW compression: 2 hours 42 mins 11 secs JG> local tar on the fileserver*: 53 mins 3 secs JG> * time /bin/sh -c "tar cf - directory | cat >/dev/null" JG> The CPU's on the fileserver was unloaded during all operations, one JG> of them was 100% idle, the other was mostly >90% IO-wait. The JG> backup-server is 98%-100% idle at all time. JG> Why is the local tar *much* faster then the bacula-fd??? And why is SW JG> compression making the backup much slower, even with unloaded CPU's? JG> I've studied the network traffic pattern with ethereal during a JG> backup, and the backup-server is responding directly at all time. It JG> is waiting for data from the fileserver. I've seen up to 400 ms JG> without a single packet from the fileserver and most of the packets JG> sent from the fileserver to the backup-server is small. JG> What can explain this? How can I debug/analyze this further. What JG> should I try? JG> / Anders JG> -- System Information: JG> Debian Release: testing/unstable JG> APT prefers testing JG> APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') JG> Architecture: amd64 (x86_64) JG> Shell: /bin/sh linked to /bin/bash JG> Kernel: Linux 2.6.15.6 JG> Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to sv_SE) JG> Versions of packages bacula depends on: JG> ii bacula-client 1.38.11-1 Network backup, recovery and verif JG> ii bacula-server 1.38.11-1 Network backup, recovery and verif JG> bacula recommends no packages. JG> -- no debconf information JG> ----- End forwarded message ----- JG> ----- Forwarded message from Anders Boström <[EMAIL PROTECTED]> ----- JG> From: Anders Boström <[EMAIL PROTECTED]> JG> Date: Fri, 18 Aug 2006 10:15:32 +0200 (CEST) JG> To: [EMAIL PROTECTED], [EMAIL PROTECTED] JG> Subject: Re: Bug#383332: bacula: backup is slow >>>>> "JG" == John Goerzen <[EMAIL PROTECTED]> writes: JG> 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. JG> Yes, I agree that this probably isn't a debian specific JG> problem. However, I'm quite sure we can rule out the backup-server as JG> ethereal tells me that the backup-server responds directly to all JG> packets from the file-server, but the file-server sometimes don't sent JG> 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. JG> I agree that software compression should slow down the backup unless JG> you are communication limited. And we are not communication limited in JG> this case. BUT we are not CPU-limited either (one CPU 100% idle during JG> backup, the other mostly >90% in IO-wait). We should *only* be disc JG> IO-limited, and even the fastest case, local tar, is very slow. At JG> only 1162 kbyte/s (bacula-fd without SW-compression), the JG> SW-compression should not slow down the backup more than a few JG> percent. As a comparison, 'gzip -6' (as should be used according to JG> the manual) on this machine sustain ~18 Mbyte/s. JG> Also, why is bacula-fd without SW-compression much slower than tar? JG> But, as you suggested, I should try the bacula-user mailing JG> list as this probably isn't debian-specific. JG> / Anders JG> ----- End forwarded message ----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
