DB2 - Problembeschreibung
Problem IC89145 | Status: Geschlossen |
STMM MAY OVERCOMMIT MEMORY ON WINDOWS SYSTEMS, RESULTING IN PAGING SPACE EXHAUSTION | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 | |
Problembeschreibung: | |
STMM doesn't account for memory that may be committed but not referenced (not backed by RAM). This memory counts towards the commit charge, which is backed by RAM and the paging file. Since STMM doesn't track whether the commit charge is getting close to the commit limit, it is even possible to end up exhausting the paging file when there is ample available system memory. STMM should protect against this. In addition, DB2's memory allocations may contribute to this scenario, since by design (for better performance), DB2 doesn't reference up front all memory it commits The best way to identify this scenario is from the Task Manager, where the Commit Charge exceeds RAM in an environment controlled by STMM. "Controlled by STMM" means that self-tuning of database memory is enabled (SELF_TUNING_MEM = ON AND DATABASE_MEMORY = AUTOMATIC) and INSTANCE_MEMORY is AUTOMATIC. In this case we expect STMM to keep overall system memory usage at a level where RAM is not over-committed. | |
Problem-Zusammenfassung: | |
Local-Fix: | |
Set INSTANCE_MEMORY to a conservative fixed value, such as 75% or 50% of RAM | |
Lösung | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Kommentar | |
This APAR is a duplicate of IC85729 | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 17.12.2012 28.01.2013 28.01.2013 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version |