ADSM-L

Re: LTO bad performance on backup stgpool

2005-07-13 10:37:45
Subject: Re: LTO bad performance on backup stgpool
From: "Warren, Matthew (Retail)" <Matthew.Warren AT POWERGEN.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 13 Jul 2005 15:37:03 +0100
Ok, some more information,

The HBA's we have the drives hanging from are 2Gbit, and have 3 drives
per HBA, I assume then they have the capacity to handle 3 LTO2 drives
streaming. Switch ports are also 2Gbit.


Also, I have managed to tun some tests and we are definitley seeing the
many-small-files issue, but wether that is the only issue I don't yet
know. Are there any other ways to tackle this small-files problem other
than tweaking movebatchsize / movesizethresh?  - So far I can think
changing the client TXNGROUPMAX value to increase the number of files
per aggregate and hence have less small pieces for the copystgpools to
handle?  Or are there any ways of forcing sizethresh over 2048 or
batchsize over 1000 ?


And, while we have been investigating this we noticed the following;

A backup stgpool has been running for a long time, we calculated it's
throughput at 8MB/sec on an an LTO1 drive.  We look at the switch port
the drive is attached to and it reports consistently that data is coming
through at an avg of 45MB/sec  for LTO1? We have checked we are actually
looking at the right port and drive, we definitley are.   How is it
possible to see 45MB/sec average (peak 60MB, for 10secs)from an LTO1
drive?  I could understand if it was 15MB/sec when we looked but
averaged out to 8MB overall, but 60MB/sec peak 45MB/sec average? Is
there SANthing I'm missing?

Matt,



Matthew.warren AT powergen.co DOT uk
Matthew_j_warren AT hotmail DOT com
http://tsmwiki.com/tsmwiki/MatthewWarren




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David Longo
Sent: Wednesday, July 13, 2005 2:53 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: LTO bad performance on backup stgpool

I can answer one of your questions easily.  Yes, the "many small files"
does affect backup stg pool, and all TSM data movements.  It will
definitely be slower to move 1000  300byte files than one 300K file
for instance.  Certainly with LTO drives, that's what I have.


David B. Longo
System Administrator
Health First, Inc.
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH      321.434.5536
Pager  321.634.8230
Fax:    321.434.5509
david.longo AT health-first DOT org

>>> Matthew.Warren AT POWERGEN.CO DOT UK 07/13/05 9:26 AM >>>
Hi *SM'ers

I am looking into why our LTO1 / LTO2 performance is so terrible (<50%
rated throughput on avg) during backup stgpools.

TSM 5.2.4
AIX 5.2
IBM 3584 library
LTO1 and LTO2 drives.

The drives hit their rated throughputs during LANFree backup.

We have 2 sites with the same devices, 3584 library with 12 LTO1 and 12
LTO2. Each site manages and clients to the others library, so siteA's
copypools reside on volumes in the library  managed by siteB and vice
versa.

We have 600MB/sec full duplex fibre connections between the two sites.
This should cope with both sites using 6LTO1 and 6LTO2 to send copypool
data to the alternate site at the same time. Max throughput from the
drives shouldn't  be more than around 550MB/sec

During backup stgpools, I am told we are throwing approx 250-300MB/sec
over the inter-site-link for the SAN. The drives at both sites appear to
run at less than half the rated throughput.

I have so far looked at movebatch and movesize, set to 1000 and 2048
currently. Performance under unix shows normal amounts of
idle/user/cpu/iowait. Database cache hit% is 99.99 on a 120GB database.
There is no log wait %.


....Does anyone have any pointers as to what to look through next? (I'm
looking for quick wins;  any very-in-depth investigations will require
my borrowing a unix resource, and is complicated by the fact we have no
test environment)

One thing I am not sure of, are tsm internal data movements affected by
the many-small-files scenario, or does this mainly impact dsmc backups?
Some of the pools being copied hold millions of tiny files (300Bytes on
avg) but not all pools.


Thanks,
Matt.


Matthew.warren AT powergen.co DOT uk
Matthew_j_warren AT hotmail DOT com
http://tsmwiki.com/tsmwiki/MatthewWarren







___________________________ Disclaimer Notice __________________________
This message and any attachments are confidential and should only be
read by those to whom they are addressed. If you are not the intended
recipient, please contact us, delete the message from your computer and
destroy any copies. Any distribution or copying without our prior
permission is prohibited.

Internet communications are not always secure and therefore Powergen
Retail Limited does not accept legal responsibility for this message.
The recipient is responsible for verifying its authenticity before
acting on the contents. Any views or opinions presented are solely those
of the author and do not necessarily represent those of Powergen Retail
Limited. 

Powergen Retail Ltd is authorised and regulated by the Financial
Services Authority for the sale and service of general insurance
products.

Registered addresses:

Powergen Retail Limited, Westwood Way, Westwood Business Park, Coventry,
CV4 8LG.
Registered in England and Wales No: 3407430

Telephone +44 (0) 2476 42 4000
Fax +44 (0) 2476 42 5432

##############################################################
This message is for the named person's use only.  It may 
contain confidential, proprietary, or legally privileged 
information.  No confidentiality or privilege is waived or 
lost by any mistransmission.  If you receive this message 
in error, please immediately delete it and all copies of it 
from your system, destroy any hard copies of it, and notify 
the sender.  You must not, directly or indirectly, use, 
disclose, distribute, print, or copy any part of this message
if you are not the intended recipient.  Health First reserves
the right to monitor all e-mail communications through its
networks.  Any views or opinions expressed in this message
are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of 
a particular entity;  and (2) the sender is authorized by 
the entity to give such views or opinions.
##############################################################

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