PROBLEM DESCRIPTION:
====================
db2diag.log entries indicating there are STMM-generated
configuration increase failures may appear when uncommited
database memory exceeds DB2's calculated available system
memory.
Under these conditions, DB2's database memory targets are
incorrectly calculated - they will be reduced, but not reduced
as far as expected.
It can occur that STMM performs the insufficient reduction of
database memory, but also transfers memory from one consumer to
another.
The decrease is done first, and succeeds, but the increase fails
when STMM performs an additional check to determine whether
there is enough system memory available given the current state
of system memory and the current configuration.
These configuration failures are not a significant problem.
The more important issue is that STMM may take a bit longer than
expected to achieve it's intended database memory target.
However, even this should not be a cause for concern. The fact
that this occurs when DB2 is holding back memory consumption due
to a large portion of uncommited database memory means that
there is little danger of overcommiting system memory. Another
way of thinking about this is that DB2/STMM is addiing
additional buffering to protect against volatile system memory
usage (which could otherwise lead to overcommiting system
memory).
Here is an example db2diag.log entry :
2009-11-18-20.23.58.915880+000 E1447A644 LEVEL: Warning
PID : 618634 TID : 8225 PROC : db2sysc
0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-8 APPID: *LOCAL.DB2.091118172320
AUTHID : db2inst1
EDUID : 8225 EDUNAME: db2stmm (SAMPLE) 0
FUNCTION: DB2 UDB, Self tuning memory manager,
stmmCheckIfFreeMemoryIsEnoughForSizeIncr, probe:648
MESSAGE : ZRC=0xFFFFEC49=-5047
DATA #1 : String, 145 bytes
There is not enough free memory for size increase. Free memory
in pages: Physical memory = 0, Instance memory = 1779788,
Database memory = 139600 |
