Our ADSM server is also the biggest CPU user in our MVS system.
However, I know that I need to increase my bufferpool, this is supposed
to improve my performance, perhaps it will reduce CPU utilization, maybe
it will bring ADSM down to second place as far as CPU utilization goes. I
do not think so, it is now far ahead of any other address space as far as
CPU utilization goes.
IBM recomendations state that bufferpool needs to be increased if the
command Q DB F=D gives you a cache hit % less than 98%.
However if you increase bufferpool space you will be using more
storage.
Good luck.
Zeida Heavener
Broward County
>>> Jerry Lawson <jlawson AT THEHARTFORD DOT COM> 08/07/97 12:01pm
>>>
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
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
|
