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 IT04320 Status: Closed

SLOW MEMORY ALLOCATIONS OR POSSIBLE SEVERE DEGRADATION DURING OOM HANDLING
DUE TO COALESCE MEMORY CHECK

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
Two different symptoms may occur depending on the release of 
DB2. 
 
DB2 Version 9.7 Fix Pack 8 or higher 
1. Windows 64-bit systems on DB2 Version 9.7 Fix pack 8 or 
higher : 
Allocating memory may be 
significantly slower for databases with larger memory footprints 
( many GBs ).  Because DB2's memory allocations on Windows are 
typically small and incremental, coalesce checks end up being 
performed on a very large number of OS allocations.  Activities 
which are intense in terms of allocating memory (such as 
bufferpool activation, creation, or increase, or initializing 
LOAD operations), may suffer some degradation as a result 
 
 
2. DB2 on UNIX platforms, DB2 Version 10.1 Fix Pack 3 or higher, 
Version 10.5 GA or higher : 
On UNIX systems where DB2 allocates large amounts of shared 
memory, the problem impacts only larger allocations where a 
relatively large number of shared memory allocations exist for 
the memory area in question (say, > 100 shared memory segments) 
AND the memory allocation is failing at some level due to a 
limit (either in DB2 or the operating system). 
 
This situation is not typical.  Large single allocations are 
rare in shared memory, and typically there are only a few large 
shared memory allocations per memory area (for example, per 
database memory area).  The performance cost in this case is 
high per coalesce memory check and the overall duration of the 
large allocation, and the database may appear to be hung for 
short periods of time.  The allocation may fail in the end or 
the coalesce check may succeed - in either case the check will 
be expensive. 
 
The call stack for both of the above symptoms will contain the 
following : 
SMemSet::checkRecommitable 
SMemSet::recommitChunksUntilTargetReached 
SMemSet::getChunksFromTree 
SMemSet::getContiguousChunks 
SMemBasePool::getNewChunkSubgroup 
 
This APAR will alter coalesce checking to remove the excessive 
overhead for both of the above symptoms.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All systems are affected                                     * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 Fix Pack 11                       * 
****************************************************************
Local Fix:
Consider using 
   db2set DB2MEMDISCLAIM=NO 
followed by db2stop; db2start, which avoids the need for any 
coalesce check. 
 
Note that DB2MEMDISCLAIM=NO disables STMM-tuning of 
database_memory, though STMM will still tune the main consumers 
(bufferpools, locklist, package cache, shared sort) inside the 
existing database_memory size.
Solution
Problem first fixed in DB2 Version 9.7 Fix Pack 11
Workaround
See Local Fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
10.09.2014
28.10.2015
28.10.2015
Problem solved at the following versions (IBM BugInfos)
9.7.FP11
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.11 FixList
This site uses cookies to make it easier for us to provide you with our services. By using our site you agree to the use of cookies.