Hi Mark,
I haven't moved to file-based disk pools yet... It was a suggestion I had
read in a manual. When it states I thread/volume is it referring to the
volume defined within TSM or the physical disk volume? Here is my device
class definition that I use for the storage pools:
Device Class Name DISK
Device Access Strategy Random
Storage Pool Count 11
Device Type -
Format -
Est/Max Capacity -
Mount Limit -
Mount Wait (min) -
Mount Retention (min) -
Label Prefix -
Library -
Directory -
Server Name -
Retry Period -
Retry Interval -
Shared -
HLAddr -
Minimum Capacity -
WORM NO
Scaled Capacity -
Last Update by (administrator) -
Thanks for responding!
********************************
Joni Moyer
Highmark
Storage Systems
Work:(717)302-6603
Fax:(717)302-5974
joni.moyer AT highmark DOT com
********************************
"Stapleton, Mark"
<mark.stapleton@B
ERBEE.COM> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: Migration Speed Has Plummeted
08/17/2005 09:04
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
Ah, there's the problem.
When you go to file-based disk pools, your migration threads are limited to
1. This is a great shock to those who are used to moving three or four
threads at a go.
TSM 5.3 is supposed to allow for multiple migration threads. That might be
your only hope.
--
Mark Stapleton (stapleton AT berbee DOT com)
Office 262.521.5627
________________________________
From: ADSM: Dist Stor Manager on behalf of Joni Moyer
Sent: Wed 8/17/2005 07:58
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Migration Speed Has Plummeted
Hi Richard,
My device class for the storage pools is DISK and I have read that it is
better to use a device type of FILE when using ATA disk. Is this true and
if so, how can I correct this? Our disk is EMC ATA Raid-3. We thought to
get cheap disk as a landing spot for our backups and then do a quick sweep
to tape, but I'm really hurting here and we also have a data center move
coming up so this is crucial for that move.
I have the caching of the migrated files turned off. I believe that this
is the only place that caching comes into play with TSM? I thank you for
your help and any suggestions!!!
Storage Pool Name ORACLE
Storage Pool Type PRIMARY
Device Class Name DISK
Estimated Capacity (MB) 1032192.0
Pct Util 96.2
Pct Migr 96.2
Pct Logical 100.0
High Mig Pct 70
Low Mig Pct 60
Migration Processes 3
Next Storage Pool TAPE_ORACLE
Maximum Size Threshold -
Access READWRITE
Description Oracle Disk Storage Pool
Overflow Location -
Cache Migrated Files? NO
Collocate? -
Reclamation Threshold -
Maximum Scratch Volumes Allowed -
Delay Period for Volume Reuse -
Migration in Progress? YES
Amount Migrated (MB) -
Elapsed Migration Time (seconds) 143029
Reclamation in Progress? -
Volume Being Migrated/Reclaimed -
Last Update Date/Time 2005-08-16 20:30:16.000000
Last Update by (administrator) LIDZR8V
Reclaim Storage Pool -
Migration Delay 0
Migration Continue YES
Storage Pool Data Format Native
Copy Storage Pool(s) -
Continue Copy on Error? -
CRC Data NO
********************************
Joni Moyer
Highmark
Storage Systems
Work:(717)302-6603
Fax:(717)302-5974
joni.moyer AT highmark DOT com
********************************
"Richard Sims"
<rbs AT bu DOT edu>
To
08/17/2005 08:35 "Joni Moyer"
AM <joni.moyer AT highmark DOT com>
cc
Subject
Re: Migration Speed Has Plummeted
Joni - Save yourself some grief and check ADSM QuickFacts for caching.
(It's a storage pool option.)
As to the migration performance: You need to do fact gathering as
part of
analysis. With older tapes and drives, you may be encountering
increasing
difficulty in writing blocks on the old tapes, which should be
reflected in
the AIX Error Log, if happening. Disk transfer speed may be related
to how
it is set up (RAID type, etc.). Disks which the OS vendor (IBM) doesn't
recognize may receive too-small queue limits. Here is one of my AIX
notes:
Disk performance Disk controllers typically
afford some
nice degree of parallelism
in order to
improve performance/
throughput. Vendors
tend to be parochail - or at
least play
it safe... If you attach an
IBM disk to
AIX, it sets attributes to a
nice number
for Queue Depth; but if you
attach a
non-IBM disk to AIX, it goes
max
conservative, limiting Queue
Depth to 1,
causing performance to suffer.
Ref: AIX doc "Setting SCSI-
Adapter and
Disk-Device Queue Limits"
System performance can
essentially
freeze if, for example, disk
formatting
is occurring on the Shark,
and system
paging space is also on the
Shark.
In AIX5, some settings you
can make:
1. Change maxperm, minperm
(away from
their default setting of
75, 25).
Possibly, lower maxperm
to 24,
minperm to 12.
2. Turn on I/O Pacing -
judiciously, as
it can also hurt
performance.
A simple way of testing disk
speed is
to time how long it takes to
write a
file of a given size, as via
command:
time dd if=/dev/zero bs=64k
count=1000
> /Some/DiskFile
where the count value may be
increased
as needed.
See also: minperm, maxperm;
Queue Depth,
disk attribute
Also, if you fall behind in migration, things just get worse as disk
fragmentation occurs, and the arm gets frantic exercise seeking all
over the
place for its next file block as a lot of distributed space on the
disk is
occupied by lingering data. This is one of the reasons that caching
is a
performance hit.
Richard Sims
On Aug 17, 2005, at 8:19 AM, Joni Moyer wrote:
>
> How do you know if caching is turned on? How/where can you turn it
> off? I
> am having lousy migration speed perfomance as well. What can I look
> at/change? I have an AIX 5.2 server at TSM 5.2.4.0 with LTO2 tape
> drives
> attached. Thanks!
>
|