home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC96296 Status: Closed

SLOW COMMITS WHEN STMM-MANAGED LOCKLIST GROWS INTO OVERFLOW

product:
DB2 FOR LUW / DB2FORLUW / A10 - DB2
Problem description:
When LOCKLIST is managed by STMM (LOCKLIST = AUTOMATIC, 
SELF_TUNED_MEMORY = ON), it is normal for the locklist to 
increase beyond its configured size and grow into overflow 
memory.  This is indicated by the following db2diag.log entry: 
 
FUNCTION: DB2 UDB, lock manager, sqlpRefillAgentLRBCache, 
probe:1000 
DATA #1 : <preformatted> 
Locklist has synchronously grown into overflow memory to avoid 
lock escalation. 
Previous locklist size: <value> 
Current locklist size: <value> 
 
While the locklist is in this overflow state, db2agents try to 
release locklist overflow when they release locks on a commit. 
A latch controlling these releases may become hotly contended, 
causing commits to take longer than normal to process.  Normally 
the STMM tuner resolves the overflow state by increasing the 
locklist configuration, and the contention is quickly resolved. 
In extreme cases, especially when the STMM tuner is delayed or 
memory is constrained, the locklist increase may not occur, 
latch contention may build, and the database may appear to be 
hung for a period of time. 
 
Issuing "db2pd -stack all" may show a large number of db2agents 
in function stacks similar to the following: 
sqloXlatchConflict 
sqlpCheckAndDecreaseLocklistOverflowUsage 
sqlplrm 
sqlpxcm1 
sqlrrcom_dps 
sqlrrcom 
sqlrr_commit 
 
db2pd -latches will show a large number of waiters on the 
"resizeLockListLatch" 
Latches: 
Address                     Holder      Waiter     Filename 
LOC        LatchType            HoldCount 
0x0700000032550110 420718     92524      sqlplit.C 
2418       SQLO_LT_SQLP_LCB__resizeLocklistLatch 1 
0x0700000032550110 420718     117196     sqlplit.C 
2418       SQLO_LT_SQLP_LCB__resizeLocklistLatch 1 
0x0700000032550110 420718     159859     sqlplit.C 
2418       SQLO_LT_SQLP_LCB__resizeLocklistLatch 1 
... 
 
If memory is overly constrained, errors such as the following 
will appear in the STMM logs (under the stmmlog directory in the 
DIAGPATH). 
FUNCTION: DB2 UDB, Self tuning memory manager, 
stmmEnforceMinSizeConstraints, probe:2364 
MESSAGE : Unable to find donor to satisfy minSize constraint 
 
and LOCKLIST will repeatedly fail to reach its minimum size 
requirement : 
FUNCTION: DB2 UDB, Self tuning memory manager, 
stmmLogRecordBeforeResizes, probe:590 
... 
Type: LOCKLIST 
... 
Current Size: 4096 
Minimum Size: 6112 
 
In this case, configuration issues should be addressed so that 
STMM is able to operate normally.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 Servers with LOCKLIST tuned by STMM                      * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 10.1 Fix Pack 4                       * 
****************************************************************
Local Fix:
Ensure that STMM tuning environments are not overly constrained 
- it is recommended that the STMM tuner has control over at 
least half of the database memory configuration.  This is to 
provide STMM sufficient flexibility to assign memory where and 
when it is required. 
 
If the environment is not overly constrained, change the 
locklist and maxlocks configuration parameters to a manual 
setting to avoid the locklist overflow contention condition.
available fix packs:
DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows

Solution
Problem first fixed in DB2 Version 10.1 Fix Pack 4
Workaround
see Local Fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
26.09.2013
11.06.2014
11.06.2014
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.1.0.4 FixList