Tape performance

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Tape performance

lsonzogni
Now i have HP Data Protector 6.11 with mhvtl emulating an MSL6000 robotic library with two Ultrium2-SCSI Tape Drive

Everything is working without problems.

I set the block size of Tape Drives to 256Kb

My linux box have Free CPU, Free Memory, SATA II Disk, ethernet card connected to Gigabit.

I will like to get better copy performance.

What can I tune ??
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Tape performance

ap2010
One way to improve performance is to switch of compression (which is just software compression) on a drive.

In the device.conf file look for the line:
 Compression: factor 1 enabled 1

and set enabled to 0

Another is to watch for double compression. If the backup software you are using is compressing the data AND the compression on the drive is on as well you loose quite some performance, so if you want to use compression, choose one and not both at the same time.

Just my two cents,

Albert
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Tape performance

Mark Harvey
The goal of this 'vtl' is to provide functionality of rqeal drives/libraries.

Performance (speed) is a secondary thought.

I wanted something to support NetBackup (my day to day paid job). This is not designed to replace commercial offerings, but something to teach, learn, demo and test with.

That all said, I've had reports of good performance with the right hardware.

I will gladly accept patches that would fix performance bottlenecks :)

Cheers
Mark

Sent from my iPad

On Sep 16, 2011, at 3:55, "ap2010 [via MHVTL - Linux Virtual Tape Library - Community Forums]"<[hidden email]> wrote:

One way to improve performance is to switch of compression (which is just software compression) on a drive.

In the device.conf file look for the line:
 Compression: factor 1 enabled 1

and set enabled to 0

Another is to watch for double compression. If the backup software you are using is compressing the data AND the compression on the drive is on as well you loose quite some performance, so if you want to use compression, choose one and not both at the same time.

Just my two cents,

Albert


If you reply to this email, your message will be added to the discussion below:
http://mhvtl-linux-virtual-tape-library-community-forums.966029.n3.nabble.com/Tape-performance-tp3339376p3339717.html
To start a new topic under MHVTL - Linux Virtual Tape Library - Community Forums, email [hidden email]
To unsubscribe from MHVTL - Linux Virtual Tape Library - Community Forums, click here.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Tape performance

lsonzogni
In reply to this post by ap2010
Reviewing backup times between disk servers and media servers (over Gigabit Ethernet), i realized that the performance is quite similar.

Ok. That's what i try:

Test1:  Compression: factor 1 enabled 1
   Backup database on SQL Server. Size 22618MB
               Start Time:   12:44
               End Time:    02:09
               Duration:     85 min
               Rate:           266 MB/min

               Space used in /opt/mhvtl/HPS001L2:  4502MB

Test1:  Compression: factor 1 enabled 0
   Backup same database on SQL Server. Size 22618MB
               Start Time:   15:37
               End Time:    16:31
               Duration:     54 min
               Rate:           419 MB/min

               Space used in /opt/mhvtl/HPS002L2:  22521MB
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Tape performance

Mark Harvey
One thing I did think of was to disable DEBUG and remove the '-g' from the build of the binaries.

The down side, is no trouble-shooting information. So, if you encounter a problem, it would have to be reproduced on a default build.

I performed a quick test of attempting to build without -DMHVTL_DEBUG and failed :(

It's been a while since I did a test build without this defined. I'll submit a fix so the package will build with MHVTL_DEBUG not being defined.

I'd be interested to see if there is any performance difference.

Cheers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Tape performance

Mark Harvey
I've just pushed commit 3138f290e1a58efe4236a8075aefd7284aea7fa4 to github which will allow 'mhvtl' to compile without MHVTL_DEBUG being defined.

So, to remove as much logging / debugging from the code, edit the usr/Makefile and comment out the following:

CFLAGS=-Wall -Wshadow -g -O2 -D_LARGEFILE64_SOURCE $(RPM_OPT_FLAGS) -I../kernel
CFLAGS += -DMHVTL_VERSION=\"$(VERSION)$(EXTRAVERSION)\"
CFLAGS += -DMHVTL_DEBUG

to

CFLAGS=-Wall -Wshadow -O2 -D_LARGEFILE64_SOURCE $(RPM_OPT_FLAGS) -I../kernel
CFLAGS += -DMHVTL_VERSION=\"$(VERSION)$(EXTRAVERSION)\"
# CFLAGS += -DMHVTL_DEBUG

Notice the '-g' is removed from the first line and the 3rd line has the '# ' added to the front of it.

As a diff:
diff --git a/usr/Makefile b/usr/Makefile
index 502028d..fda8db1 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -36,9 +36,9 @@ MHVTL_CONFIG_PATH ?= /etc/mhvtl
 CONFIG_PATH = $(shell echo $(MHVTL_CONFIG_PATH) | sed -e s'/\//\\\//g')
 HOME_PATH = $(shell echo $(MHVTL_HOME_PATH) | sed -e s'/\//\\\//g')

-CFLAGS=-Wall -Wshadow -g -O2 -D_LARGEFILE64_SOURCE $(RPM_OPT_FLAGS) -I../kernel
+CFLAGS=-Wall -Wshadow -O2 -D_LARGEFILE64_SOURCE $(RPM_OPT_FLAGS) -I../kernel
 CFLAGS += -DMHVTL_VERSION=\"$(VERSION)$(EXTRAVERSION)\"
-CFLAGS += -DMHVTL_DEBUG
+# CFLAGS += -DMHVTL_DEBUG
 CFLAGS += -DUSR=\"$(USR)\"
 CFLAGS += -DMHVTL_HOME_PATH=\"$(MHVTL_HOME_PATH)\"
 CFLAGS += -DMHVTL_CONFIG_PATH=\"$(MHVTL_CONFIG_PATH)\"

Loading...