Networker

Re: [Networker] Best way to evaluate drive speed?

2006-07-12 00:14:08
Subject: Re: [Networker] Best way to evaluate drive speed?
From: Itzik Meirson <imeirson AT MBI.CO DOT IL>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 12 Jul 2006 07:02:21 +0300
The best procedure to run speed test on the drives is to use the
"bigasm" directive described in the "Performance Tuning Guide".
This will do a backup from memory thus testing all components from
"client to device"
If you use this procedure on the backup server you get the maximum
throughput the backup server is able to push to your drives.
You should of course play with "client parallelism" and "target
sessions" to distribute the backup to single/multiple drives with
varying multiplexing.
If you run this for your storage node client, you will get the maximum
throughput for the storage node drives.
If you run this for a "general" client in your data zone you will be
also testing the client capabilities to push the data through the
network to your designated drives.
Itzik

-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On Behalf Of George Sinclair
Sent: Wednesday, July 12, 2006 03:16
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Best way to evaluate drive speed?

I think I'm asking too many questions here, but it's related so ...

How do we best determine if we're getting reasonable write speed on our
tape drives?

We have 4 SDLT 600 drives in a LVD Quantum library attached to a Linux
storage node. We're using SCSI interface with dual channel host adapter
cards (LSI 22320 Ultra320) which supplies 160 MB/channel. Drive1-2 are
daisy chained to channel A. Drives 3-4 are daisy chained to channel B. 
Perhaps each drive should be on its own channel, but given the speed of
the channel it seemed OK to have two drives share a channel. Was not
going to have more than 2 drive per channel, however. But, burst
transfer speed does list as 160 max, so with two drives that would be
320 so maybe they should each be on separate channels. Anyway, the
product information indicates that these drives have a speed of 35
native, 70 MB/sec with compression. I assume this is a best case
scenario, and I doubt we'll be able to match those in practice, and it
might make a difference if the data is local to the snode or coming over
the network, but how do we determine if we're getting good results?

This brings up 3 questions:
1. What are the vendors doing to claim these numbers? How are they
writing the data during the tests so as to optimize the speed to claim
the best possible results?

2. What is a good way to determine if the drives in your library are
functioning at their proper speeds?

3. Does sending more save sets to a tape device really increase the
speed, and if so, why? I thought I've seen this behavior before wherein
the speed increases (to a point) when more sessions are running, but
maybe that was coincidental. I mean, why would one large save set (as in
one large enough such that when you're doing a full, it will take a
while so there's no shoe shining effect and the drive can just stream
along)  not do the same as multi sessions?

I was thinking to first run some non-Legato tests by tarring a 2 GB
directory on the storage node directly to one of the devices, time the
operation and then do the math. Perform a tar extract to ensure it
worked correctly. I don't think I can run multiple concurrent tar
sessions to the same device, though, like multi-plexing in NetWorker. 
Will this still yield a good idea of the drives speed? Not sure this
would fill the buffer fast enough or generate good enough burst speed
like if I'm running multiple save sets in NetWorker, but I refer to
question 2. above?

If sending more sessions to the device does increase the speed then when
using NetWorker to send multiple sessions to the device, so as to better
fill the buffer and increase drive speed, how can I best capture the
results? Is it obvious enough to simply create a group, place the snode
in the group, specify 'All' for the client's save sets and then just
launch a full and then look at the start and completion times for the
group and how much total was backed up and do the math to get an average
drive speed? There are 5 file systems on the snode, and 4 are very small
(under 300 MB) except for /usr which is about 6 GB, so we all know which
one will still be cranking on a full long after the others are done. 
Will this be a fair test? Maybe better to create say 4 separate named
paths of 1 GB each, for example, and list those as the save sets? Again,
this gets back to question 2. above.

Thanks.

George
 

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems wit this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER