Re: TSM Performance with 3584 LTO-2 Drives
2005-10-21 07:37:27
you might want to try using the "dd"
command on AIX with a large test file as David proposes.
something like
#dd if=/test_dir/test_file of=/dev/rmt0
bs=256 /* bs=block size expressed
in factors or multiples of 4096. 256 should be the default LTO blocksize*/
in this way you should get the "OS
perspective" on data transfer to tape and be able to compare to TSM
backup performance. one thing to remember is that dd is not an application,
so the application overhead that TSM (as any other application vs command)
introduces has to be considered when comparing results obtained in the
two cases. I would also run some iostat monitoring while performing the
test, so as to see how your read from disk performance is doing and compare
that to write to tape performance.
Cordiali saluti
Gianluca Mariani
Tivoli TSM Global Response Team, Roma
Via Sciangai 53, Roma
phones : +39(0)659664598
+393351270554
(mobile)
gianluca_mariani AT it.ibm DOT com
----------------------------------------------------------------------------------------------------
Resembles Life what once was held of Light,
Too ample in itself for human sight ?
An absolute Self--an element ungrounded--
All, that we see, all colours of all shade
By encroach of darkness made ?--
Is very life by consciousness unbounded ?
And all the thoughts, pains, joys of mortal breath,
A war-embrace of wrestling Life and Death ?
David McClelland/UK/Contr/IBM@IBMGB
Sent by: "ADSM: Dist Stor Manager"
<ADSM-L AT VM.MARIST DOT EDU>
21/10/2005 11:53
Please respond to
"ADSM: Dist Stor Manager" |
|
To
| ADSM-L AT VM.MARIST DOT EDU
|
cc
|
|
Subject
| Re: TSM Performance with
3584 LTO-2 Drives |
|
Hi Jim,
If in doubt, back to basics - quite simply, I'd start by performing a simple
backup or archive of a large file (or set of large files) of several GB's
(use the 'lmktemp' command in AIX to create if you haven't got big files
handy) locally from your TSM server's client (i.e. take network out of
the equation), and send it to a management class with a copygroup defined
to send the data directly to one of your tape drives.
In this way, without too much messing around, you'll quickly and easily
see much more of a 'raw' performance figure as to what your tape drive
can handle with TSM is writing to it (ok, balanced against how quickly
the source file is being read from disk on the TSM server/client), and
be able to use that as a benchmark to work out the ballpark of where your
performance bottleneck lies (e.g. a SAN, zoning issue, TSM migration or
tape mount issue).
HTH,
David McClelland
Storage and Systems Management Specialist
IBM Tivoli Certified Deployment Professional (ITSM 5.2)
SSO UK Service Delivery – Storage Services
IBM Global Services – IBM United Kingdom
| |
John Schneider <Schneider_JohnD AT EMC DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
21/10/2005 05:13
Please respond to
"ADSM: Dist Stor Manager" |
|
To
| ADSM-L AT VM.MARIST DOT EDU
|
cc
|
|
Subject
| Re: [ADSM-L] TSM Performance
with 3584 LTO-2 Drives |
|
You may have stated this earlier in the thread, but could you clarify this
statement?
> I've double-checked the zoning, and everything seems as it should
be
> (server and disk in one zone and server and tape drives in another
zone).
Does the server have separate HBAs for the disk and tape traffic? I
mean,
certain HBAs do nothing but disk, and separate HBAs do nothing but tape?
That is a TSM requirement.
Best Regards,
John D. Schneider
Technology Consultant - Backup, Recovery, and Archive Practice
EMC² Corporation, 600 Emerson Road, Suite 400, St. Louis, MO 63141
Phone: 314-989-3839 Cell: 314-225-9997 Email: Schneider_JohnD AT emc DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bill Kelly
Sent: Thursday, October 20, 2005 8:36 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM Performance with 3584 LTO-2 Drives
On Thu, 20 Oct 2005, Chet Osborn wrote:
> Thanks for the replies, but no luck yet.
Another possibility...have a look at APAR IC46349:
When running a move data or migration to a collocated storage
pool bad performance may be seen, with 5.3.1.0 server.
.
The bad performance appears to be triggered by a combination
of the number of volumes in the source and target storage pools
and the number of files and filespaces involved in the specific
operation.
I'm not sure how bad 'bad performance' is; it's all pretty vague-sounding.
But, this is fixed at 5.3.2.0, so it might be worth a try.
Regards,
Bill
>
> The data being migrated all belonged to a single node, and only two
> tape mounts were involved.
>
> The drive firmware is up to date. I'll be damned if I can figure out
> how to determine what the 3584 library firmware level is or how to
> download it. The device driver (Atape) software is up to data as of
a
> month o\r so ago.
>
> I've double-checked the zoning, and everything seems as it should
be
> (server and disk in one zone and server and tape drives in another
zone).
>
> At 02:23 PM 10/20/2005, you wrote:
> >Another factor to consider: does the tape pool in question have
> >collocation turned on? If so, then depending on the number
of tapes in
> >the pool, the type of collocation in effect and the number of
client
nodes
> >or filespaces to be migrated, there could be a very large number
of tape
> >mounts occurring. With only two drives, and depending on
the mount
> >retention period specified on the device class, I could believe
that an
> >awful lot of that 10.5 hours might've been spent fiddling around
with
tape
> >mounts, idle drives, etc., and not actually writing data.
> >
> >Regards,
> >Bill
> >
> >Bill Kelly
> >Auburn University OIT
> >334-844-9917
> >
> > > It also wouldn't hurt to verify that your library and drive
code
> > > (firmware) are up-to-date.
> > >
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
On Behalf
Of
> > > Jim Skinner
> > > Sent: Thursday, October 20, 2005 11:36 AM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: Re: [ADSM-L] TSM Performance with 3584 LTO-2 Drives
> > >
> > > I believe the first thing to check is the zoning of the
fiber channel
> > > network. TSM server and disk in one zone and in a different
zone put
tsm
> > > server and tape. We had a similar problem.
> > > >>> osborn AT RPI DOT EDU 10/20/05 11:22 AM >>>
> > > Hi,
> > >
> > > We're recently connected a 3584 with one L52 frame containing
2 LTO-2
> > > fiber attached drives to our AIX server. We'll be using
FAStT SATA
> > > disk as a primary storage pool and migrating from disk to
tape. Can
> > > anyone with a similar setup provide any statistics
on how this works
> > > in the real world, i.e. MB/sec or GB/hour from disk to tape.
> > >
> > > A test migration of 259 GB (152422 files) took 10.5 hours
to
> > > complete. This seems like abysmally slow performance, or
is it
> > > reasonable with a large numbers of small files?
> > >
> > > TSM version: 5.3.1
> > >
> > > MoveBatchSize 500
> > > MoveSizeThresh 512
> > >
> > > AIX version: 5.1
> > >
> > > Chet Osborn
> > > Systems Programmer
> > > Rensselaer Polytechnic Institute
> > >
> > > Jim Skinner
> > > The University of Kansas Hospital
> > > Westwood Campus
> > > Information Technology Systems
> > > 2330 Shawnee Mission Parkway, Suite 201/068
> > > Westwood KS 66205-2005
> > > 913-588-4787
> > >
> > >
> > > Confidentiality Notice:
> > > The information contained in this email message is privileged
and
> > confidential information and intended only for the use of the
> > individual or entity named in the address. If you are not
the
> > intended recipient, you are hereby notified that any dissemination,
> > distribution, or copying of this information is strictly
> > prohibited. If you received this information in error,
please
> > notify the sender and delete this information from your computer
> > and retain no copies of any of this information.
> > >
>
|
|
|