[email protected]
[Top] [All Lists]

Bug#383332: marked as forwarded (bacula: backup is slow)

Subject: Bug#383332: marked as forwarded bacula: backup is slow
From: Debian Bug Tracking System
Date: Mon, 09 Oct 2006 09:04:19 -0700
Your message dated Mon, 9 Oct 2006 10:29:33 -0500
with message-id <[email protected]>
has caused the Debian Bug report #383332,
regarding bacula: backup is slow
to be marked as having been forwarded to the upstream software
author(s) [email protected], [email protected], 
[email protected]

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Subject: backup is slow
From: John Goerzen
Date: Mon, 9 Oct 2006 10:29:33 -0500
Hello Bacula folks,

We received this message at the Debian bug-tracking system, and thought
that this is probably a more appropriate forum for it:

----- Forwarded message from Anders Boström <[email protected]> -----

From: Anders Boström <[email protected]>
Date: Wed, 16 Aug 2006 17:32:28 +0200 (CEST)
To: Debian Bug Tracking System <[email protected]>
Subject: bacula: backup is slow

Package: bacula
Version: 1.38.11-1
Severity: normal

We have a problem with very long backup-times of our file-server.

The file-server is only used for NFS and is quite heavily loaded. It
is a Debian etch amd64 with a kernel running on a Athlon 64
X2 3800+ (dual core) with 2Gb mem and two 500 Gb discs in raid1. ext3
is used as filesystem, with dir_index enabled.

The backup-server is also a Debian etch amd64 but with a
kernel and an Athlon 64 3200+ CPU with 512 Mb mem. Both bacula-sd and
bacula-dir is running on the backup-server, as well as a
mysql-daemon. Discs are used for backup.

The file-server and the backup-server are connected via an GE-network
without loss.

I've done some measurements on a ~7.5 Gb directory tree with 88208
files (just one user-account):

bacula backup without SW compression:   1 hour 45 mins 2 secs
bacula backup with SW compression:      2 hours 42 mins 11 secs
local tar on the fileserver*:           53 mins 3 secs

* time /bin/sh -c "tar cf - directory | cat >/dev/null"

The CPU's on the fileserver was unloaded during all operations, one
of them was 100% idle, the other was mostly >90% IO-wait. The
backup-server is 98%-100% idle at all time.

Why is the local tar *much* faster then the bacula-fd??? And why is SW
compression making the backup much slower, even with unloaded CPU's?

I've studied the network traffic pattern with ethereal during a
backup, and the backup-server is responding directly at all time. It
is waiting for data from the fileserver. I've seen up to 400 ms
without a single packet from the fileserver and most of the packets
sent from the fileserver to the backup-server is small.

What can explain this? How can I debug/analyze this further. What
should I try?

/ Anders

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to sv_SE)

Versions of packages bacula depends on:
ii  bacula-client                 1.38.11-1  Network backup, recovery and verif
ii  bacula-server                 1.38.11-1  Network backup, recovery and verif

bacula recommends no packages.

-- no debconf information

----- End forwarded message -----
----- Forwarded message from Anders Boström <[email protected]> -----

From: Anders Boström <[email protected]>
Date: Fri, 18 Aug 2006 10:15:32 +0200 (CEST)
To: [email protected], [email protected]
Subject: Re: Bug#383332: bacula: backup is slow

>>>>> "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

----- End forwarded message -----

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • Bug#383332: marked as forwarded (bacula: backup is slow), Debian Bug Tracking System <=