ADSM-L

Re: Tape performance

2003-07-29 11:46:01
Subject: Re: Tape performance
From: Jin Bae Chi <Jbaechi AT CSCC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Jul 2003 11:45:31 -0400
Remember that tar cmd writes only 10k bytes and dd cmd you gave 256k. So, tar 
cmd can give the impression of poor performance. Also, FC address could be 
another factor when used as sigle with mig from disk to tape. My 2 cents...


Gus


>>> brenda.collins AT US.ING DOT COM 07/22/03 02:41PM >>>
The test to move data from the operating system was just a 10GB file,
although it was all zero's.

The tape performance on TSM was achieved by doing a disk to tape.  We took
the ratings from doing a backup storagepool to tape.  We tried it with
storagepools that had filesystems and databases, the results are fairly
close to the same.  Our disk is on the SAN so we do not go through the
network.

Here are results from some new tests we just performed today.  (Our drives
are 9840B)

DD Test with CBN and RMT drivers


# mt -f /dev/rmt/6cbn status
StorageTek 9840B tape drive:
   sense key(0x6)= Unit Attention   residual= 0   retries= 0
   file no= 0   block no= 0
# time dd if=/dev/zero of=/dev/rmt/6cbn bs=256k count=40000
40000+0 records in
40000+0 records out

RESULT:  38.78 MB/Sec

real    4m24.29s
user    0m0.17s
sys     1m13.05s
# time dd if=/dev/zero of=/dev/rmt/15mt bs=256k count=40000
40000+0 records in
40000+0 records out

real    5m15.57s
user    0m0.19s
sys     1m50.37s
#

RESULT:  32.5 MB/Sec

Here is a core file used to test performance, with 453 MBytes, it take
average of 2.2 minutes...

# time tar -cvf /dev/rmt/14mt core
a core 453736K

real    2m22.37s
user    0m0.44s
sys     0m28.28s
# time tar -cvf /dev/rmt/14mt core
a core 453736K

real    2m19.16s
user    0m0.25s
sys     0m28.79s




|---------+---------------------------->
|         |           Richard Sims     |
|         |           <rbs AT BU DOT EDU>     |
|         |                            |
|         |           07/22/2003 12:23 |
|         |           PM               |
|         |           Please respond to|
|         |           "ADSM: Dist Stor |
|         |           Manager"         |
|         |                            |
|---------+---------------------------->
  
>------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                 |
  |       To:       ADSM-L AT VM.MARIST DOT EDU                                 
                                                        |
  |       cc:                                                                   
                                                 |
  |       Subject:  Re: Tape performance                                        
                                                 |
  
>------------------------------------------------------------------------------------------------------------------------------|



>I am wondering if there is something in TSM that throttles the tape
>performance we should be getting.  I can do a dd test from the operating
>system to the tape drive and with that receive 2 GB per minute (32 MB/sec)
>but when I do a test through TSM, I only get 1 GB per minute.
>
>My environment is:
>TSM 5.7.0 on Solaris 8
>Server: Sunfire 880
>Tape drives are 9840 Fibre attached.
>
>As a result, we are questioning the value of putting in the more expensive
>tape drives when we can't seem to pump the data through as expected.
>
>Any ideas of what I might look at would be appreciated.

Now, why did you not tell us what the test was?  :-)
Perspective and context is everything when trying to respond to postings.
You very much did the right thing in getting isolated benchmark numbers
first.

Was the test a single, very large file so as to keep database updating out
of the picture, rather than many small files?  Was the client co-resident
on
the server system as to keep network contention out of the picture?  All
them factors.

  Richard Sims, BU

<Prev in Thread] Current Thread [Next in Thread>