StoreEver Tape Storage
cancel
Showing results for 
Search instead for 
Did you mean: 

Poor Performace with on SDLT-Tapes

Thomas Auel
Occasional Visitor

Poor Performace with on SDLT-Tapes

We have big problems backing up our data from about 20 Proliant 8500R (8 Xeons, and 2GB RAM, Windows NT4) Servers with 2 Emulex LP6000 HBA to SDLT-drives connected via SAN. One HBA is responsible for the disks, the other one for the Tapedevices.We are using Legato Networker 6.1.2 and the Tapedrives are in a ATL-P3000 Library with a FC230 FC-to-SCSI-Bridge. The maximum throughput i saw was about 5 MB. On a Solaris-Server the performace is much better, also the Tapelibrary an the FC-Bridge are the same.
SDLT Perfomance Problems
3 REPLIES
Vincent Fleming
Honored Contributor

Re: Poor Performace with on SDLT-Tapes

Your performance is a function of more than just the tape configuration...

CPU speed, Operating System disk performance, disk array performance, and backup software performance can all affect your backup speed, and probably accounts for the difference between your UNIX box and your NT box.

It may be something as simple as the blocksize that the server is using during the backup - NT often uses 8K - Solaris is usually 64K. This can make a very significant difference is transfer rates. Check both systems during a backup and see what blocksize they're using.

You may not be able to do much about this performance difference.

Good luck!

Tschau!
No matter where you go, there you are.
Vincent Farrugia
Honored Contributor

Re: Poor Performace with on SDLT-Tapes

Hello,

Regarding block size... This can make a huge difference. We once had a similar issue and when we changed the block size to the recommended value, all of a sudden the backups went full speed again.

The recommended block size for SDLTs is 32k.

HTH,
Vince
Tape Drives RULE!!!
Joseph T. Wyckoff
Honored Contributor

Re: Poor Performace with on SDLT-Tapes

If this question involved Omniback, I would advise you to use a NUL drive, instead of a tape drive, to better get a feel for where the bottleneck is.

A NUL drive (file /dev/null or c:\temp\nul) is of course a very fast 'tape drive' that can be used on pretty much any machine... if your backup software allows it.

By using a NUL device on each of your several computers you may be able to see the issue as a disk bottleneck, or a network bottleneck, or perhaps even a tape drive bottleneck.

If you use a null device on the same machine that your tape drive is attached to, and if the 'backup' is substantially faster, this says that data is able to get to the machine faster than your normal tape drive can handle... which implies the tape drive is the bottleneck.

On the other hand, if this null drive is pretty much the same speed, the bottleneck is elsewhere... like the disk io or network io systems.

Assuming the network is involved... move (create) the null drive on another server, and benchmark again.

Good Luck.
Omniback and NT problems? double check name resolution, DNS/HOSTS...