home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IT07075 Status: Geschlossen

STMM MAXIMUM TARGETS MAY BE TEMPORARILY TOO HIGH, SOME SWAPPING MAY OCCUR
ON LINUX SYSTEMS

Produkt:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problembeschreibung:
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.
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 systems running on Linux, AND STMM is tuning             * 
* Database_Memory with INSTANCE_MEMORY set to AUTOMATIC        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 10.5 Fix Pack 7                       * 
****************************************************************
Local-Fix:
Specify a fixed INSTANCE_MEMORY or DATABASE_MEMORY setting that 
limits DB2's memory usage to reasonable values (this can be done 
based on checking historical database_memory tunings in the 
db2diag.log or STMM log)
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:
10.02.2015
16.02.2016
16.02.2016
Problem behoben ab folgender Versionen (IBM BugInfos)
Problem behoben lt. FixList in der Version
10.5.0.7 FixList