PH36114: HIGH DISCARDDATA ACTIVITY DURING POOLINAC THREAD DEALLOCATION

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When a DDF connection goes inactive (typically at commit), the
  thread is pooled. If a thread is pooled longer than x minutes
  without being reused, the (pooled) thread will be deallocated
  (x is determined by the POOLINAC ZPARM setting).
  When the workload is very spiky, Db2 will create a large number
  of new DBATs to accommodate this extra work.If the spike of
  activity is very short, those threads are not likely to get
  reused and will sit in the pool until they are deallocated by
  POOLINAC processing.
  Cleaning up a large number of threads in a short time can result
  in extra stress for the system. One such stress area that has
  been observed is that, as part of thread deallocation, its
  storage is cleaned up. When REALSTORAGE_MANANAGEMENT ZPARM is
  AUTO or ON, this will also trigger DISCARDDATA processing of
  storage areas above the bar. When a lot of pooled threads are
  cleaned up at the same time by POOLINAC processing, a spike in
  DISCARDDATA requests will put more pressure on RSM. To process
  these requests some ECSA storage is needed by RSM. If the
  customer is low on ECSA storage, this spike in DISCARDDATA can
  result in ECSA shortage.
  
  
  SQA exhausted Abend080 rc x'FF0022FF' in module IAXV6 with high
  cpu consumption in the RASP address space
  
  
  Additional keywords and symptoms:
  **********************************
  DB2DDF DDF DISCARDDATA REALSTORAGE_MANAGEMENT
  POOLINAC
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All Db2 12 for z/OS Distributed Data                         *
  * Facility (DDF) Users.                                        *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Possible ECSA storage shortage due to                        *
  * spike in MVS Real Storage Manager                            *
  * (RSM) requests to DISCARDDATA storage                        *
  * areas above the bar.                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply corrective PTF when available                          *
  ****************************************************************
  When concurrent distributed client request demand
  increases, Db2 DDF creates server threads (DBATs) to handle
  the processing. When that client processing demand subsides,
  DDF will have pooled the DBATs while waiting for more work
  requests from those existing or future new client
  connections. Every two minutes, a DDF error monitor task
  runs and attempts to terminate any pooled DBAT that has
  been in the pool for an elapsed time more than the
  POOL THREAD TIMEOUT (DSN6FAC POOLINAC) subsystem parameter.
  If the DBATs which serviced the demand were pooled at
  approximately the same time, the DDF error monitor task
  could request a large number of pooled DBATs be terminated
  at approximately the same time which would result in a
  large concurrent demand for Db2 to clean up the storage
  used by the DBATs. These requests to clean up storage,
  when REALSTORAGE_MANAGEMENT ZPARM is AUTO or ON, will
  trigger a spike in DISCARDDATA requests. The spike will
  put pressure on RSM to request ESQA storage which is
  needed by RSM to process these DISCARDDATA requests. As
  more concurrent DISCARDDATA requests occur, the ESQA
  storage requests will eventually spill over to the ECSA.
  If the system is low on available ESQA/ECSA storage, this
  spike in DISCARDDATA processing can result in an ECSA/ESQA
  shortage and/or an increase in CPU utilization.
  

Problem conclusion

• Db2 DDF error monitor has been changed to only terminate a
  maximum of 50 pooled DBATs that have exceeded their pool
  inactivity time (POOLINAC) during a DDF error monitor cycle.
  For terminating pooled DBATs, the DDF error monitor cycle has
  been changed to once every 15 seconds.
  

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:

  UI75788

Modules/Macros

• DSNLEDDA
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RC10 PSY UI75788

     UP21/06/17 P F106

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.