|
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 ?? |
|
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 |
|
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:
|
|
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 |
|
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 |
|
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)\" |
| Powered by Nabble | See how NAML generates this page |
