William,
Being at the level of TSM you are at, could you be experiencing the
wonderful 'system objects' problem? This is the level we were at when
it really bit us and we started experiencing the same slow downs you are
currently experiencing (we couldn't get through expiration in a day any
longer, reclamation couldn't stay caught up, DB growth, etc.).
Once we went to 4.2 and performed the cleanup backupgroups and actually
deleted all of our system objects and just started over on that
filespace, we have been able to rid ourselves of these issues. But, the
total process of getting through everything took about 5 months.
1. Since then, we have been able to reduce our 35 GB DB utilization
from 92% to 46%. Our buffpoolsize is set to 212992 and we are running
really well right now.
2. No experience with damage to DB.
3. Ran an auditDB in development and cancelled it after 30 hours. Not
feasible for the production environment.
Cinda Mullen
Ascension Health ISD
-----Original Message-----
From: William White [mailto:White AT UNICC DOT ORG]
Sent: Thursday, June 12, 2003 6:51 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM Performance OS/390
Dear helpful TSMers,
We are having trouble with performance. Symptoms are extremely
slow
expiration, database backup, migration, backup, restore, admin commands.
As an example, after an incremental database backup of about 360000
pages,
there was a message on the console saying all of the pages were backed
up
and yet it took about an hour for the process to end. Normal
performance
of database backup in our environment is about 15000 pages every 30
seconds
(when the progress message is issued) Yesterday, I was seeing a few
hundred pages increase between messages.
TSM environment:
z800 (2066 0A2)
OS/390 V2.10 (32 bit mode)
STK 9840 tape (20 GB cartridges)
HDS 7700 E DASD
TSM server 4.1.6
150 clients, mostly wintel
250 GB per night backup
I know that the server software is out of date and we are working
on
getting V5.
I think the basic problem is bad performance of the TSM database:
tsm: ADSM>q db f=d
Available Space (MB): 57,120
Assigned Capacity (MB): 52,516
Maximum Extension (MB): 4,604
Maximum Reduction (MB): 4,396
Page Size (bytes): 4,096
Total Usable Pages: 13,444,096
Used Pages: 12,319,606
Pct Util: 91.6
Max. Pct Util: 91.6
Physical Volumes: 25
Buffer Pool Pages: 200,000
Total Buffer Requests: 98,206,939
Cache Hit Pct.: 97.27
Cache Wait Pct.: 0.00
Backup in Progress?: No
Type of Backup In Progress:
Incrementals Since Last Full: 2
Changed Since Last Backup (MB): 923.31
Percentage Changed: 1.92
Last Complete Backup Date/Time: 06/11/2003 13:38:46
My Questions:
1) Does the size of the buffer pool seem appropriate? What values are
other sites using?
2) Does anyone have any experience of pervasive damage to the TSM
database?
3) Does anyone think an AUDIT DB would help? I am reluctant to try
that
because I think it would take a very long time and the server would be
out
of service for all that time. I did an AUDIT DB years ago and it ran
over
9 hours on a 6GB database. Extrapolating, an AUDIT DB might finish in
four
days ( a reasonable guess ? )
Thanks,
www.
---------------------------------------------------------
William White
Service Delivery Section
International Computing Centre (ICC)
e-mail: white AT unicc DOT org
|
