William,
Check RMF if you have it, this will give you more info on whether TSM is being
squeezed for cpu or is suffering slow i/o. my favourite from your symtoms are
cpu deprivation.
I was going to suggest that you recycled the TSM address space, to clear any
memory leaks, but I can see from your tottal buffer requests that it has not
been that long, since your last recycle. Was the performance ok before that
recycle ?
Your database utilisation rate should fpr preference be kept below 90% and your
cacke hit % is lower than it should be (98% plus), but if your performance
problem is recent and these values have not changed much recently they are not
likely to have been directly responsible for the performance drop.
In answer to your specific questions, I would say that your bufferpool is way
too big
My database is half the size of yours, but my Buffer Pool Pages are only
12,288
There is a relationship between the TSM region size/bufferpoolsize and available
real memory where you can in fact significantly worsen performance by seemingly
giving TSM more resources. I would check that my TSM region size was 512 mb and
I would try an initial bufferpool size similar to mine.
If you had serious problems with the database, I would expect you to see error
messages,
and I would then expect you to take advice from support and this would be the
only scenario for which I would even consider an audit database. Then after
consideration, I still would not do it if there was another solution,
John
William White <[EMAIL PROTECTED]> on 06/12/2003 12:50:39 PM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: John Naylor/HAV/SSE)
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: [EMAIL PROTECTED]
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric, Southern Electric, SWALEC and S+S
are trading names of the Scottish and Southern Energy Group.
**********************************************************************
