DB2 - Problembeschreibung
Problem IT06551 | Status: Geschlossen |
SLOW MEMORY ALLOCATIONS OR POSSIBLE SEVERE DEGRADATION DURING OOM HANDLING DUE TO COALESCE MEMORY CHECK | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
Problembeschreibung: | |
***** The Windows-specific symptoms have not been addressed by this APAR in versions 10.1, 10.5 (the version 9.7 APAR IT04320 does contain fixes for all symptoms). Please see version 10.1 APAR IT21207 and version 10.5 APAR IT21209 for the complete fix. ***** 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-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * All systems are vulnerable * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 Version 10.5 Fix Pack 7 * **************************************************************** | |
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. | |
Lösung | |
Problem first fixed in DB2 Version 10.5 Fix Pack 7 | |
Workaround | |
See Local Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 16.01.2015 16.02.2016 27.06.2017 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version | |
10.5.0.7 |