On Tue, 2007-08-07 at 12:39 -0400, Dan Langille wrote:
On 7 Aug 2007 at 11:57, Tod Hagan wrote:
On Thu, 2007-08-02 at 20:31 -0400, John Drescher wrote:
I doubt that the tape drive is the cause. Did you make any database
changes?
Sort of. A more recent postgresql package was
On Thu, 2007-08-02 at 20:31 -0400, John Drescher wrote:
Below I've included some output from tapeinfo as the scsi tape driver is
the most likely source of the slowdown. I've tried 'mt -f /dev/nst0
stsetoptions buffer-writes async-writes' with no effect.
I'd really appreciate some ideas
On 7 Aug 2007 at 11:57, Tod Hagan wrote:
On Thu, 2007-08-02 at 20:31 -0400, John Drescher wrote:
Below I've included some output from tapeinfo as the scsi tape driver is
the most likely source of the slowdown. I've tried 'mt -f /dev/nst0
stsetoptions buffer-writes async-writes' with no
Dear John
May I ask if there are jobs queued waiting to be backed up. Also are you
using MySQL.
I had a similar problem with2.0.3 - what I noticed is a job starting
with high rate and as jobs got queued behind it the the rate declined
and also the system started to consume swap space and
All,
We recently upgraded the machine running Bacula to Red Hat Enterprise
Linux 5 from RHEL 3 and now see a much slower transfer rate during
backups. The version of Bacula is unchanged, 1.38.8, except for
re-compilation against the updated libraries.
One backup, which ran at 8772.2 to 12671.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tod Hagan wrote:
All,
We recently upgraded the machine running Bacula to Red Hat Enterprise
Linux 5 from RHEL 3 and now see a much slower transfer rate during
backups. The version of Bacula is unchanged, 1.38.8, except for
re-compilation
Below I've included some output from tapeinfo as the scsi tape driver is
the most likely source of the slowdown. I've tried 'mt -f /dev/nst0
stsetoptions buffer-writes async-writes' with no effect.
I'd really appreciate some ideas on increasing the backup speeds to the
levels we used to get.
