DB2 - Problem description
Problem IC77375 | Status: Closed |
APPLICATION SHARED MEMORY (APPSHRH) MIGHT LEAK WHEN ADDING ROWS TO MDC TABLES. | |
product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problem description: | |
Application shared memory (appshrh) might leak when inserting rows to MDC tables. This symptom could be perceived by virtue of "db2pd -db <db_name> -memblocks top". The memblock will increase %Bytes and/or %Count even after the insert commits or the application terminates. 1st Round: Top memory consumers in AppCtl memory set: PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File 20 appshrh 100904064 93.40 788313 72.06 3450 1560397958 2nd Round: Top memory consumers in AppCtl memory set: PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File 20 appshrh 143394048 95.33 1120266 79.21 3450 1560397958 3rd Round: Top memory consumers in AppCtl memory set: PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File 20 appshrh 479587200 98.43 3746775 92.31 3450 1560397958 When an insert into an MDC table occurs, the composite block index is probed for the logical cell corresponding to the dimension values of the record to be inserted. To improve the performance of a transaction inserting multiple rows into an MDC, a cache of cell values is maintained to quickly find the target cell for the next insert without having to probe the composite block index. The allocated memory should be freed at the end of a transaction or when an application terminates. But there is a problem where DB2 does not free the entire list. | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All users * **************************************************************** * PROBLEM DESCRIPTION: * * Application shared memory (appshrh) might leak when * * inserting rows to MDC tables. * * * * * * This symptom could be perceived by virtue of "db2pd -db * * <db_name> -memblocks top". The memblock will increase * * %Bytes and/or %Count even after the insert commits or the * * application terminates. * * * * 1st Round: * * Top memory consumers in AppCtl memory set: * * PoolID PoolName TotalSize(Bytes) %Bytes TotalCount * * %Count LOC File * * 20 appshrh 100904064 93.40 788313 * * 72.06 3450 1560397958 * * * * 2nd Round: * * Top memory consumers in AppCtl memory set: * * PoolID PoolName TotalSize(Bytes) %Bytes TotalCount * * %Count LOC File * * 20 appshrh 143394048 95.33 1120266 * * 79.21 3450 1560397958 * * * * 3rd Round: * * Top memory consumers in AppCtl memory set: * * PoolID PoolName TotalSize(Bytes) %Bytes TotalCount * * %Count LOC File * * 20 appshrh 479587200 98.43 3746775 * * 92.31 3450 1560397958 * * * * When an insert into an MDC table occurs, the composite block * * index is probed for the logical cell corresponding to the * * dimension values of the record to be inserted. To improve * * the performance of a transaction inserting multiple rows * * into an MDC, a cache of cell values is maintained to quickly * * find the target cell for the next insert without having to * * probe the composite block index. * * * * The allocated memory should be freed at the end of a * * transaction or when an application terminates. But there is * * a problem where DB2 does not free the entire list. * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 version 9.7.0.5. * **************************************************************** | |
Local Fix: | |
Restart the database to free the leaked memory in appshrh. | |
available fix packs: | |
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows | |
Solution | |
The problem has been fixed in DB2 9.7.0.5. | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 06.07.2011 07.12.2011 07.12.2011 |
Problem solved at the following versions (IBM BugInfos) | |
9.7.0.5 | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.7.0.5 |