*** Original Author: ADSM-L @ MARIST - ** Remote User **; 08/07/97 11:02am
>Received: from VM.MARIST.EDU by AUDUCADM.DUC.AUBURN.EDU (IBM MVS SMTP V3R1)
> with TCP; Thu, 07 Aug 97 11:02:45 CDT
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R3)
> with BSMTP id 5900; Thu, 07 Aug 97 11:36:47 EDT
>Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU
> (LMail V1.2b/1.8b) with BSMTP id 3732; Thu, 7 Aug 1997 11:36:45 -0400
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (LISTSERV release 1.8c) with NJE
> id 6860 for ADSM-L AT VM.MARIST DOT EDU; Thu, 7 Aug 1997 11:36:42
> -0400
>Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
> V1.2b/1.8b) with BSMTP id 3720; Thu, 7 Aug 1997 11:36:42 -0400
>Received: from interlock.itthartford.com by VM.MARIST.EDU (IBM VM SMTP V2R3)
> with TCP; Thu, 07 Aug 97 11:36:40 EDT
>Received: from higmx.itthartford.com by interlock.itthartford.com with SMTP id
> AA06393 (InterLock SMTP Gateway 3.0 for <adsm-l AT VM.MARIST DOT
> EDU>); Thu,
> 7 Aug 1997 11:36:37 -0400
>X400-Originator: jlawson AT higmx.thehartford DOT com
>X400-Recipients: adsm-l AT VM.MARIST DOT EDU
>X400-Mts-Identifier: /ADMD=INTERNET/C=US/;0012900001723404000002
>X400-Content-Type: P2-1988 (22)
>Priority: Urgent
>Message-ID: <0012900001723404000002*@MHS>
>Date: Thu, 7 Aug 1997 12:01:07 -0400
>Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>From: Jerry Lawson <jlawson AT THEHARTFORD DOT COM>
>Subject: ADSM MVS Server Performance
>To: ADSM-L AT VM.MARIST DOT EDU
>
Date: August 7, 1997 Time: 10:23 AM
From: Jerry Lawson
The Hartford Insurance Group
(860) 547-2960 jlawson AT thehartford DOT com
-----------------------------------------------------------------------------
The MVS performance guy in our shop has finally come over to see me about
The MVS performance guy in our shop has finally come over to see me about
ADSM performance. He was concerned about performance during the mornings
primarily, and also in the late afternoons. These are key times for us, but
we took a look at ADSM, and we did find some interesting things happening...
The first concern was Expiration processing. We had been starting this at
9:00PM; we discovered it was often still running at 7:00AM the next morning!
Our DB is 7.7GB in size - it consists of 5 3380 volumes residing on
Iceberg/RAMAC RVA DASD. Total utilization is approximately 82 %. Stats show
that I have a 0.00% wait time.
Because the Expiration was running so long, it was tripping over a lot of
other stuff that we have to run each day - for example, at 5:00 AM, we run a
backup of the major DASD pool that supports our Server backups - this pool is
18+GB in size, and an average night lately has approximately 17.5 GB of data
being written to the pool. The backup was conflicting with the expiration
apparently, as it was not getting a good start, and therefore often running
until 11:00AM. Occasionally, if we had a heavy night, this storage pool
would overflow, and we would have a migration running at the same time - a
really bad idea. We will generally cancel this migration if things look
clear, and wait for the scheduled migration later in the day - 3:00PM
Another problem is the Reclaim processing. Obviously, a by-product of the
expiration processing, this was also running throughout the morning.
So... we were faced with a couple of choices to reduce CPU utilization.
Unfortunately, we did not have a good handle on which tasks were causing the
most CPU utilization. (I did look at an RMFMON report, and was shocked to
find that ADSM IS THE BIGGEST CPU USER ON THE SYSTEM! (Even bigger than
HSM).
The biggest impact item seems to be Expiration - we are considering running
this on weekends only. I know others do this - if you have, I am curious to
find out what the impacts of this were.
We are running a test at the moment (from Wednesday through Saturday), and I
expect that I will see that the actual Expiration will not run all that much
longer than the daily one did, but I am worried about the reclaim processes -
I am afraid that they will become unmanageable. I say this because of
something we did about a month or so ago - we had a reclaim threshold of 97%
on our Copypool tapes, and we decided to change it to 96% to see what the
results would be. The reclaims continued for a week until we gained the 1%
back. Now this was with 3480 tapes (we now use 3490), and some of the tapes
are out of the silo, and so had to be re-inserted. But it was not a cheery
though.
Any other observations MVS users? How big of a CPU user is ADSM in your
shop? If you want to use the same quick and dirty test I did - Logon to TSO,
from a Ready, type in RMFMON, and when you get the menu, select PF1. Page
through the results by hitting the "enter" key. One of the columns is CPU
used - look for ADSM and compare it to the other tasks. At this point (on a
machine that has been up since Sunday) ADSM has consumed 77,517 CPU seconds,
while DFHSM has used 28,851, and the master scheduler has only used 5,099.
It would seem to me that ADSM has some serious performance CPU consumption
issues to address. Is there anything I can do to help myself out?
Signed,
Consumed in Hartford
-----------------------------------------------------------------------------
Jerry
Jerry
*** Comments From: STEWAJM - Stewart, Mike; 08/07/97 12:54pm
You might check your bufpoolsize. If your devices are staying
that busy you might be able to speed the process by
reducing db activity.
My db size is about 5 gb, and expiration processing takes
about 30 minutes...that is on a 9672-R3 model, to give you
a processor speed reference.
Yes, ADSM is a _big_ CPU consumer. Your processor consumption
seems comperable to mine (assuming our processor speeds are
comperable).
|
