ADSM-L

TSM Performance OS/390

2003-06-12 07:51:22
Subject: TSM Performance OS/390
From: William White <White AT UNICC DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 12 Jun 2003 13:50:39 +0200
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

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