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. |
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. |
