Jim
The fact that you say other (non-TSM) backup jobs to the tapes have not
degraded and also large TDP backups are not affected, seems to rule out
the tape performance completely. I don't know anything about the model
of disk that you mentioned, but is it a SAN and does the diskpool share
the disk system with any other apps, if so, are the apps that share the
disk, producing an unusually high load. Also, are the disks showing any
errors.
The only other factors that I can think of is your TSM database
performance (what's the cache hit %) and the type of data that is being
migrated (ie extremely large amounts of very small files)
Have you recently changed any of the following settings in dsmserv.opt.
The values that I have may not necessarily be the optimum for MVS.
MoveSizeThresh 2048
TxnGroupMax 256
MoveBatchSize 1000
Lastly, you mention that your code level is 5.2.2.0. There are 3 patch
releases at that level, it may be worth looking through the apars for
the patch releases to see if one matches your problem.
The following stands out
PQ85160 DELETE ARCHIVE CAUSES POOR PERFORMANCE/HIGH CPU UTIL
Have you been deleting archives recently ?
HTH
Leigh
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
James Duncan
Sent: 17 August 2005 09:31
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Migration Speed Has Plummeted
Hi there...
I hope someone can offer some help with the following problem..
Server Tivoli Storage Manager for MVS V5 R2 L2.0
84 clients - mixture of Windows, Netware, AIX, Lotus Notes, Solaris.
Disk Pool IBM 3390-3 Mainframe Disks
Tape Pool IBM 3590-E Magstar x4 2x fibe channels to drives
We back up around 220 Gb of data to the disk pool overnight, then
migrate (with cacheing on) to cartridge in the morning.
On 2nd of this month, the average speed of the migration from disk to
cartridge plummeted by almost 10 Gb/Hour, then by another 4 Gb/H the
following day.
It has since averaged under 20 Gb/Hour, when previously (before 2nd
August) it was 35 Gb/H.
All other major Tivoli functions (expiration, reclamation) seem to be
constant in duration. We do not collocate (yet).
Two large mail (Lotus Notes) server go straight to cartridge, and are
unchanged in duration (ave. 27Gb/hour running together) All other
non-Tivoli backups to cartridge are also unchanged in duration.
The Tivoli server performance group has not been changed, so is getting
the same CPU.
I have had to add another migration process to ensure it finishes before
the cartridge drives are needed for the evening batch, but with only
four drives, this is causing contention.
I can think of no changes to Tivoli that would have caused the loss of
transfer speed. Has anyone else encountered such a thing?
The ADSM-L archives offer nothing specific for this problem, so I am
wondering if it is a Tivoli issue at all.
Thanks,
Jim Duncan
This email and any attachments are confidential. They may contain
privileged information and are intended for the named addressee(s) only.
They must not be distributed without our consent. If you are not the
intended recipient, please notify us immediately and do not disclose,
distribute or retain this email or any part of it. Unless expressly
stated, opinions in this email are those of the individual sender and
not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this email and any
attachments.
Please note that the content of this email or any of its attachments may
contain data that falls within the scope of the Data Protection Acts and
that you must ensure that any handling or processing of such data by you
is fully compliant with the terms and provisions of the Data Protection
Act 1984 and 1998.
N Brown Group plc. Registered office: Griffin House, 40 Lever Street,
Manchester, M60 6ES. Registered in England No.814103.
|
