If the STMM tuner detects a "0" benefit/cost for all STMM-tuned
areas, and only a single database is being tuned, the free
memory target will switch from the minimum to the maximum value
in the free memory target range. (eg. from 1% to 10% of RAM).
This may trigger a corresponding decrease in the STMM-tuned
configuration (eg. large decrease in bufferpools). The
assumption is that the database is idle, but often this is a
very temporary condition, or is a result of limiting STMM tuning
to areas which often don't have a continuous high need for
memory (eg. locklist, package cache). The magnitude of the
switch is large and can disrupt performance. Instead, the
minimum free target should be maintained (the STMM tuner will
still react to constrained memory conditions as part of normal
tuning).
Note this issue applies only when database_memory is automatic
and stmm tuning is enabled.
The STMM logs will contain an entry similar to the following :
FUNCTION: DB2 UDB, Self tuning memory manager,
stmmGetDBMemDataAutomatic, probe:3867
DATA #1 : String, 409 bytes
Configured memory on the system: 83886080
Memory currently available on the system: 9763323
Configured memory on the partition: 67108864
Memory currently available on the partition: 765120
Set's configured size: 64637056
Overflow left: 4693216
Uncommited size: 3777200
Target consumer size: 55963646
Current consumer size: 59943840
Max growth: 0
Average benefit: 0
Partition benefit: DB: SAMPLE Benefit: 0
or
Global benefit: DB: SAMPLE Benefit: 0
In this case, the Average benefit is 0 for the Sample database.
It is also the only database competing for memory, so is also
the highest benefit database - showing up in the line with
Partition or Global benefit. The target memory consumption will
be much lower as compared with normal STMM tuning when this
condition is detected. |
