IBM Support

PM65360: HIGH MSTR SRB CPU TIME IN DB2 V10

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • MSTR SRB time is increased a lot after migrating to V10.
    There's an internal growth of a storage cache, the management of
    that cache is causing MSTR CPU to be consumed.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All DB2 HDBAA10 V10 users.                   *
    ****************************************************************
    * PROBLEM DESCRIPTION: High DB2 MSTR SRB CPU time is observed  *
    *                      and some STATs fields not externalized  *
    *                      to IFCID1.                              *
    ****************************************************************
    * RECOMMENDATION: INSTALL PTF                                  *
    ****************************************************************
    During DB2 storage contraction, pool FREE or pool RESET of 64bit
    pools, high MSTR CPU time may be observed if the pool contains
    used blocks more than 8K in size.  This CPU increase may occur
    at commit or at thread deallocation or both, especially when the
    storage is contained in the CTV64STP or other thread pools
    which persist in cached threads beyond deallocation.
    While trying to analyze the reason for the CPU increase, it was
    observed that fields QSST_RSMAX_WARN, QSST_P64DISNUM,
    QSST_P64DISBLK, QSST_P64DISPGS, and QSST_CONTSTOR_NUM were
    missing from IFCID1.
    

Problem conclusion

  • The logic for discarding the REAL frame backing for 64bit pools
    is changed to detect when blocks do not contain backed pages
    since the last time the discard was done.  This may occur
    during pool contraction or thread commit or deallocation.
    This avoids the IARV64 DISCARDDATA call to z/OS unless there
    are backed pages indicated.
    Also, the missing fields were externalized to the IFCID1.
    

Temporary fix

  • *********
    * HIPER *
    *********
    

Comments

APAR Information

  • APAR number

    PM65360

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    A10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-05-23

  • Closed date

    2012-07-10

  • Last modified date

    2012-08-08

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

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

    UK80191

Modules/Macros

  • DSNSCON2 DSNSQST  DSNSVSVP
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK80191

       UP12/07/27 P F207

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.

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
08 August 2012