DB2 - Problem description
Problem IC74549 | Status: Closed |
STMM TARGETS ARE TOO HIGH DUE TO INCORRECT PRIVATE MEMORY SET "CACHED" VALUE, RESULTS IN HIGH NUMBER OF REQUESTMEMORY ERRORS | |
product: | |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 | |
Problem description: | |
On HP, Linux, and Solaris, DB2 private memory set allocations cannot be reduced by other memory areas. Freeing activity in the private memory set itself can reduce memory usage, but nothing can be decommitted from outside This means that the "cached" instance memory should really be 0 for private memory. Since STMM tunes memory based on being able to force down the private cached memory in order to support additional database memory, STMM database memory targets can be too high, causing tuning failures and possible performance issues from contention at the Instance Memory level. This problem only impacts environments with a fixed Instance Memory limit on HP, Linux, and Solaris where private memory usage is high relative to the overall instance memory usage. Example db2diag.log entries: 2011-01-29-18.00.22.920729-360 I3501E963 LEVEL: Warning PID : 14476 TID : 47766453610816PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 DB : SAMPLE APPHDL : 0-26 APPID: *LOCAL.DB2.110129031555 AUTHID : db2inst1 EDUID : 129 EDUNAME: db2stmm (SAMPLE) 0 FUNCTION: DB2 UDB, SQO Memory Management, SqloMemController::requestMemory, probe:50 MESSAGE : ZRC=0x8B0F0000=-1961951232=SQLO_NOMEM "No Memory Available" DIA8300C A memory heap error has occurred. DATA #1 : String, 28 bytes Attempt to get memory failed DATA #2 : unsigned integer, 8 bytes 1206583296 DATA #3 : unsigned integer, 8 bytes 10 < means STMM tried 10 times to steal cached memory > ... FUNCTION: DB2 UDB, SQO Memory Management, SqloMemController::getPartitionStats, probe:14 DATA #1 : <preformatted> PRIVATE - Current size : 1522176 KB, HWM : 2930240 KB, Reserved : 521600 KB Private memory remains with a high cached value (the "Reserved" lable is wrong, it should be "Cached", similar to db2pd -dbptnmem output). | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * Systems on Solaris, Linux, HP with STMM tuning Database * * Memory (SELF_TUNING_MEM = ON AND DATABASE_MEMORY = * * AUTOMATIC) AND a fixed Instance Memory limit. * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 Version 9.5 Fix Pack 8 or higher. * * Alternatively, use a fixed Database Memory setting to * * control main DB2 memory usage as opposed to a fixed Instance * * Memory setting * **************************************************************** | |
Local Fix: | |
Change INSTANCE_MEMORY to AUTOMATIC (use fixed DATABASE_MEMORY values instead if desired) | |
available fix packs: | |
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows | |
Solution | |
Problem first fixed in DB2 Version 9.5 Fix Pack 8 | |
Workaround | |
not known / see Local fix | |
BUG-Tracking | |
forerunner : APAR is sysrouted TO one or more of the following: IC74550 follow-up : | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 17.02.2011 12.08.2011 12.08.2011 |
Problem solved at the following versions (IBM BugInfos) | |
9.5.FP8 | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.5.0.8 |