DB2 - Problem description
Problem IC89145 | Status: Closed |
STMM MAY OVERCOMMIT MEMORY ON WINDOWS SYSTEMS, RESULTING IN PAGING SPACE EXHAUSTION | |
product: | |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 | |
Problem description: | |
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 Summary: | |
Local Fix: | |
Set INSTANCE_MEMORY to a conservative fixed value, such as 75% or 50% of RAM | |
Solution | |
Workaround | |
not known / see Local fix | |
Comment | |
This APAR is a duplicate of IC85729 | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 17.12.2012 28.01.2013 28.01.2013 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) |