To make the case even more strange, performance on other network tasks was quite normal where the gigabit  connection was maxed ASAP.

After some digging, the problem turned out to be that the server was running the old default drivers for the NIC (Broadcom BCM5708S netXtreme II GigE). Windows update has in the latest Windows versions become better on delivering driver updates but that was not the case this time.

After installing the newest drivers from Broadcom`s website the performance jumped straight to gigabit even on Data Protector.

How-to:

1: Halt your virtual machine.

You need to stop your virtual machine before going wild with the drive. Virsh stop <vm name>, or virsh destroy <vm name> if it somehow wont stop.

2: Create a disk with the extra space needed:

qemu-img create -f raw 5gig.img 5G

3: Merge it into the disk you are working with

cat 5gig.img >> yourdisk.img

4: Boot up and and partition your drive.

Then start up your virtual machine again with virsh start <vm name>. If you use Windows server, all you need to do is to visit disk managent, right click your drive with little free space and choose “extend partition”. The job takes seconds and does not require any reboot.

My setup:
CPU: Intel(R) Core(TM)2 Quad CPU Q9300
RAM: 16G
Drives: 11 drives in one RAID6 with drives split over two cheap PCI-E x4 controllers and the motherboard`s internal controller.

I will test my system between each tuning by using dd for read and write testing. Since i have a nice amount of RAM available, i will use a test file of 36G. (bs=16k) Between each test (both read and write), i clear the OS disk cache with the command:

sync;echo 3 > /proc/sys/vm/drop_caches

Tuning stripe_cache_size

stripe_cache_size affects RAM used by mdadm to writing of data. Ubuntu`s default value is 256, you can verify your value by doing:

cat /sys/block/md0/md/stripe_cache_size

And changing it with:

echo *number* > /sys/block/md0/md/stripe_cache_size

Test results with stripe_cache_size=256
- Write performance: 174 MB/s

Not to good, i therefore increased it some levels, each level with result is described below:

Test results with stripe_cache_size=512
- Write performance: 212 MB/s

Test results with stripe_cache_size=1024
- Write performance: 237 MB/s

Test results with stripe_cache_size=2048
- Write performance: 254 MB/s

Test results with stripe_cache_size=4096
- Write performance: 295 MB/s

Test results with stripe_cache_size=8192
- Write performance: 362 MB/s

Test results with stripe_cache_size=16384
- Write performance: 293 MB/s

Test results with stripe_cache_size=32768
- Write performance: 326 MB/s

So, going from 256 to 32K ~doubled my write performance, not bad!

Tuning Read Ahead

Time to change a bit on read ahead, which should impact read performance. Default read ahead value is “1536″, and you can change it with the command:

blockdev --setra *number* /dev/md0

Test results with Read Ahead @ 1536
- Read performance: 717 MB/s

Test results with Read Ahead @ 4096
- Read performance: 746 MB/s

Test results with Read Ahead @ 32768
- Read performance: 731 MB/s

Test results with Read Ahead @ 262144
- Read performance: 697 MB/s

Test results with Read Ahead @ 524288
- Read performance: 630 MB/s

So oposite of the write performance tuning, this actually became worse for most of the settings. So 4096 is the best for my system.

In conclution

This is just an example on how different settings can have rather large impact on a system, both for the better and for the worse. If you are going to tune your system you have to test different setting for yourself and see what works best for your setup.  Higher values does not automaticly mean better results. I ended up with “stripe_cache_size=8192″ and “Read Ahead @ 4096″ for my system.

If you want to make sure that your changes is saved when rebooting the system, remember to add these commands (with your values) in /etc/rc.local.

I decided to simply remove the RAID and only use one drive for Windows 7. So far it appears to be very stable again, so hopefully the issues was related to the combination of two SSD`s in RAID0 on a AMD-RAID controller.

Time will tell.

1. Start off by checking the software for the UPS,  or install it if missing (HP Power Manager)
2. Consider giving the battery fuse a kick, it`s the fuse placed back up to the right amongst the outlets (Leave it off for 15 seconds++)*
3. If you still dont have any luck, replace your battery/batteries.
4. If you are using ERM`s, make sure that the UPS knows about them. (Read the manual)

PS: Remember to have redundant power set up, since you might have to give the whole ups a little kick if it`s acting very silly

* = When turning off the battery fuse, the outlets will still get power from your input power, it just disables the batteries. When turning it on again, the UPS will start a recharge of them.

Cannot load exchanger medium (Target drive is busy.)

From Data Protector Manager (or from the backup reports), you have a tape “stuck” in your tape station. This is something that can happen for example if the tape station looses connection to the software using the tape station, (for example  a crash on the server) and the software is not setup to automaticly correct the issue itself.

If you want to eject the tape in use you will normally find a option for it on the tape station itself. But a good thing to do is to set up Data Protector to automaticly eject a tape that has taken over a drive.

1) Start Data Protector Manager GUI
2) Select Devices and Media
3) Right click on the library, select properties
4) Go to Control Tab, and select “Eject medium”  under the busy drive handling topic

The “fix” for this issue is to simply disable the DVD-rom in the BIOS completely (Simply set the Module Bay Device to off). As of now (june 2010), a fix is not available for this issue.

Edit: And yes, this does work for me! My boot time went from 2-4 minutes to seconds!