On Tue, 11 Jul 2006 20:16:24 -0400, George Sinclair
<George.Sinclair AT NOAA DOT GOV> wrote:
>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?
I would expect to achieve similar results to the manufacturers speeds IF
there are no other bottlenecks in the system.
The compressed speed depends on the data (and the drives compression
algorithm and buffer size) we average 4 times compression on LTO-1 for our
SAP/Oracle data.
>2. What is a good way to determine if the drives in your library are
>functioning at their proper speeds?
bigasm. Not sure about Linux but on Solaris networker (6.1.3) speed
reporting is ~25% below reality, check with either the equivalent of
iostat or manually time the actual transfer of a known amount of data to
the tape.
>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?
If a single savestream is not keeping the drive streaming (slow
client/network) then adding more savestreams will increase the speed up to
the maximum the drive can acheive - after that more savesets just slow up
restores. You have to think about backups (and restores ) from the clients
disk to the backup servers tape in terms of possible bottlenecks both on a
single saveset and on multiple savesets - I have seen a network where a
single connection was limitited to 20MB/s but there was no problem sending
4 savesets at the same time so a client that can produce 20MB/s per
saveset backsup at 80MB/s while 4 savesets are going at a time as soon as
it gets to a single saveset the throuput drops down to 20MB/s - not a good
effect if the client has one only one large partition!
>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?
Tar and cp are slow, as previously mentioned if you want to check bigasm
speeds are reasonable the use dd. With LTO-1 (15 GB/s native) I find that
bigasm writes at ~20MB/s so there is some compression.
>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.
Not quite sure what you will achieve with this - use bigasm to check the
storage node can drive the tape drives at full speed - with multiple
concurrent bigasm test and the drive target sessions set to 1 you can see
if there is a bottleneck in having 2 drives per SCSI bus and if the dual
SCSI HBA can drive 4 drives at max at the same time.
If you don't have a problem with this test then any speed the storage node
actually saves data at is being bound by the available CPU, disk
throughput or overheads in reading the filesystem.
Hope this helps a bit.
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
|
