I just found this item in IBMLink. At last, expiration will get better!
See the details under 'problem conclusion'.
--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
Item PQ26279
Item PQ26279
APAR Identifier ...... PQ26279 Last Changed..99/05/20
ADSM V3 EXPIRATION PROCESSING PERFORMANCE IS SLOW. OTHER ADSM
PROCESSES MAY STALL OR STALL EXPIRATION WAITING ON LOCKS.
Symptom ...... PR PERF Status ........... CLOSED PER
Severity ................... 2 Date Closed ......... 99/05/20
Component .......... 565511901 Duplicate of ........
Reported Release ......... 310 Fixed Release ............ 999
Component Name ADSM MVS/VM SER Special Notice
Current Target Date ..99/07/22 Flags
SCP ...................
Platform ............
Status Detail: Not Available
PE PTF List:
PTF List:
Release 310 : PTF not available yet
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
There have been problems in ADSM V3 server expiration processing
which kept the server from expiring all of the data that it
should. With the 3.1.2.20 level all the fixes for these
expiration problems are officially available. Upon running at
this level (or a previous fixtest level with these fixes)
expiration processing will initially run quite a while longer
to do initial catching up. Once the initial expiration
processes has completely travered the db at this level
subsequent expirations will still run a bit longer than they
in the past as it will now always be checking the areas it had
been missing in the past. Due to the long running nature of the
initial and in some cases subsequent expiration processes there
is the possibility of other server processing running into
lock contention with expiration. This can cause expiration or
the other process to stall for a while waiting on the needed
lock. ADSM development is investigating possible enhancements
to expiration processing in hopes of improving the current
performance and reducing the possibility of lock contention.
This APAR is intended to address this performance enhancement.
LOCAL FIX:
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All Version 3 server users at ptf level 3.1.2.1 or above.
****************************************************************
* PROBLEM DESCRIPTION: *
The server expiration algorithm performance has been
degraded relative to expiration performance prior to this
server level.
The performance degradation is the result of the fix for
IX81990. This fix corrected a situation in expiration
where it could skip deleting files that were actually
eligible for expiring. This skipping of files could
cause the server db utilization to grow. This fix
caused the performance to degrade because MORE database
entries needed to be evaluated to insure that all
necessary files were being evaluated and expired as
needed. The fix for apar IX81990 is valid and the
increased number of files to be evaluated can not
be avoided.
****************************************************************
* RECOMMENDATION: *
Apply the ptf with this fix once it is available.
****************************************************************
The expiration algorithm has been modified to allow the
process to use multiple server threads. This allows the
server to search and deleted more quickly as these tasks
are shared between two server threads instead of being
done by a single server thread as they had in the past.
In support of this new expiration algorithm, a new command
has been added. The command is "CANCEL EXPIRATION". This
will cancel an expiration process if there is one currently
running. Please note that this does NOT require the process
id to be specified. By not needing the process id, this
command can be scheduled using the server administrative
command scheduling utility to help manage expiration
processing and the time it consumes.
PROBLEM CONCLUSION:
The server expiration algorithm performance was degraded
as a result of a valid fix. This fix was necessary to prevent
the skipping of files for expiration and potential database
growth as these files were not expired appropriately.
To offer relief to this performance degradation in the
expiration process, the expiration algorithm and server
have been changed as follows:
1) The algorithm itself has been altered to allow it to use
multiple threads. This will allow the process to spread the
work of searching for files to expire and the actual deletion
of files between these multiple threads.
2) The command "CANCEL EXPIRATION" has been added. This allows
for the cancelling of an expiration process without knowing
what the process id for expiration is.
3) The expiration algorithm is now restartable. If the
process is cancelled and subsequently restarted, it will
restart where it left off instead of always from the
beginning of the expiration management table in the server
database.
So as to better manage expiration, if expiration takes too
long to run in a given customer environment, this fix
should offer relief and better management of the expiration
process. For example, if it is desired to ONLY have expiration
run for 2 hours each day from 8:00 at night to 10:00 at
night. A server administrative scheduled command can be
set up to start expiration each night at 8:00. And than
to manage having expiration ONLY run for 2 hours, another
scheduled command can be entered to issue the
"CANCEL EXPIRATION" command each night at 10:00. By doing this
the customer can manage having expiration run just 2 hours
a night. Also, since expiration is now restartable, the
expiration process over the course of these 2 hour nightly
runs, will be able to progress through the ENTIRE
expiration management database table instead of always
restarting from the beginning.
By providing this combination of new function in expiration
and the new CANCEL EXPIRATION command, the expiration
processing can be explicitly controlled by the needs of the
customer environment and offer relief to the change in
expiration performance.
|
