On Thu, 22 May 2008 13:10:39 -0400
"John Drescher" <drescherjm AT gmail DOT com> wrote:
> > I searched the archives and found a thread on bacula-users from Dec07 with
> > subject "LTO-4 backup rates", and also a thread on bacula-devel from Sep07
> > with subject "Bacula performance with a 64512 block size".
> >
> > I just got a new IBM TS3310 with 3 LTO-4 SAS drives, and after my initial
> > Bacula setup, I'm getting ~23MB/s writing to the drive.
> >
> I get that speed with a 4 year old 2Ghz Opteron system and a LTO2
> drive which is part of an autochanger.
>
Yes, thanks for rubbing it in ;)
> >
> > I have verified that the local disk is not the bottleneck as well as the
> > actual source (a SAN volume via 10gigE) as bonnie++ gets me numbers as high
> > as 330MB/s. I have also verified that I can write to all three drives at
> > once (~24MB/s each) and otherwise load the server (disk I/O, CPU) without
> > affecting the 23MB/s write rate. It seems like writing to the tape drive
> > is the bottleneck.
> >
> > Asking on another forum I got a suggestion to increas the "block size" and
> > "buffer size", but it is not clear to me how to do that with my hardware
> > and Bacula.
> >
> > I see the "Maximum Network Buffer Size" directive, and I'll try testing the
> > performance with different values for that, but is there anything else I
> > can tweak? Another thread I found in the archive suggests that the current
> > default buffer size is 64KB.
> >
> > We were consistently getting ~60MB/s to our LTO-3 drives with older
> > hardware and Bacula, so I was hoping for ~120MB/s.
> >
> > This isn't specifically a Bacula software problem, I'm getting ~23MB/s with
> > "btape fill". This is Bacula 2.2.8 on CentOS 5.1 on an IBM x3650.
> >
> > Any suggestions?
> >
> Are you using spooling? Are you backing up millions of files? Is your
> database on the same system as the one that is being backed up?
No spooling yet, not particularly large numbers of files yet. The backup
source is not the same machine as the mysql db.
I just ran some dd tests, and it seems like block size makes a big difference,
and with 64KB block size I get ~25MB/s. An LTO-4 tape is loaded into /dev/nst1
which is an LTO-4 IBM ULT3580-TD4 drive:
# date; dd if=/dev/zero of=/dev/nst1 bs=1024k count=10240; date
Thu May 22 12:56:38 EDT 2008
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 137.136 seconds, 78.3 MB/s
Thu May 22 12:58:55 EDT 2008
# date; dd if=/dev/zero of=/dev/nst1 bs=64k count=10240; date
Thu May 22 13:02:38 EDT 2008
10240+0 records in
10240+0 records out
671088640 bytes (671 MB) copied, 26.8409 seconds, 25.0 MB/s
Thu May 22 13:03:05 EDT 2008
# date; dd if=/dev/zero of=/dev/nst1 bs=2048k count=10240; date
Thu May 22 13:09:47 EDT 2008
10240+0 records in
10240+0 records out
21474836480 bytes (21 GB) copied, 245.657 seconds, 87.4 MB/s
dd errors out if I try bs greater than 2M:
# date; dd if=/dev/zero of=/dev/nst1 bs=4M count=10240; date
Thu May 22 13:32:53 EDT 2008
dd: writing `/dev/nst1': Device or resource busy
1+0 records in
0+0 records out
0 bytes (0 B) copied, 1.63167 seconds, 0.0 kB/s
Even though MaxBlock is ~16M, if I'm reading tapeinfo output correctly:
# tapeinfo -f /dev/sg5
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULT3580-TD4 '
Revision: '7A31'
Attached Changer: No
SerialNumber: '1310023210'
MinBlock:1
MaxBlock:16777215
SCSI ID: 1
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x48
Density Code: 0x46
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
Block Position: 4
Regards,
--
Alex Chekholko
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
