PM04401: PAGE LATCH CONTENTION DUE TO DELAYS IN TIMER PROCESSING.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Severe page latch contention in datasharing caused by delays in
  processing internal timer requests. Those delays are in turn
  caused by delays in storage block processing for timer requests
  resulting from a build up of castout control blocks in the
  storage pool.
  Keywords: ABTMQLTH ABPSP2 CRB
  DB2STGLK/K
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: DB2 data sharing users.                      *
  ****************************************************************
  * PROBLEM DESCRIPTION: Storage growth and possible performance *
  *                      degradation due to buildup of long      *
  *                      chains of castout request blocks.       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  If a castout engine is processing a request which takes a long
  time to complete (such as for GBP checkpoint processing), it is
  possible for a very large number of new castout requests to be
  queued up for the same object.  Each request is represented by a
  castout request block (CRB), so a large number of CRBs may end
  up being allocated.  This can cause an increase in the size of
  the storage pool they're allocated in (the BB1RMID pool, also
  known as the ABPSP2 pool).  Additionally, the lengthy storage
  block chains can result in a performance degradation when
  allocating and freeing storage in that pool.  This performance
  degradation may also manifest itself as an increase in page
  latch wait time since page latch waits require allocating and
  freeing a block in that same pool.
  

Problem conclusion

• The castout logic has been modified to no longer queue up a CRB
  for a new castout request when an engine is already actively
  processing a castout request which renders the new one redundant
  (e.g. if DB2 is already casting out the entire pageset, it makes
  no sense to queue up a CRB for a CLASST request).
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK53768 UK53769

Modules/Macros

• DSNB1PCD DSNB1PCO DSNB5PCO DSNDPB
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• R810 PSY UK53768

     UP10/02/09 P F002

• R910 PSY UK53769

     UP10/02/09 P F002

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.