This problem affects DB2/Linux systems using STMM to tune the
overall database memory usage based on system memory
availability, i.e.
- INSTANCE_MEMORY is not set to a fixed value
- DATABASE_MEMORY is set to AUTOMATIC
- SELF_TUNING_MEM is set to YES
If the Linux VMM is under pressure to reclaim memory, some DB2
shared memory pages may become unmapped, i.e. removed from the
db2sysc process page table. If the memory is not subsequently
swapped out, DB2's self tuning memory manager (STMM) will assume
this memory is part of the file cache, and available for other
usage. This may cause STMM maximum memory targets to be too
high.
This should be a temporary condition, but may trigger additional
swapping on Linux systems
- STMM memory targets are conservative, which generally avoid
the need for reclaiming shared memory.
- If the unmapped shared memory is swapped out, it is accounted
for and memory targets reduced
- Even if maximum targets are too high, there must be a
performance benefit to commit additional memory to DB2 to
increase memory usage. For this to occur, generally memory is
in high demand and frequently accessed, in which case any
unmapped memory is likely to be re-referenced within a short
time period, increasing the "Mapped" counter to be again in line
with the Shmem counter.
The overshoot in STMM's maximum memory target can be calculated
by subtracting the "Mapped" field from the "Shmem" field in the
/proc/meminfo output. For example :
Mapped: 91855876 kB
Shmem: 119439256 kB
In this case there is approximately 119439256-91855876 =
27583380 or 27GB of unmapped shared memory, causing STMM's
maximum memory target to be 27GB too high. It does not mean
that STMM will increase the configuration by this amount, but it
is a possibility, and STMM may not correctly detect a
constrained memory situation on the system. |
