|
Problem IC77376
|
Status: Closed |
APPLICATION SHARED MEMORY (APPSHRH) MIGHT LEAK WHEN ADDING ROWS TO MDC TABLES. |
| product: |
DB2 FOR LUW / DB2FORLUW / 910 - 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 9.1.0.11. *
**************************************************************** |
| Local Fix: |
Restart the database to free the leaked memory in appshrh. |
| available fix packs: |
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
|
| Solution |
The problem is fixed in DB2 9.1.0.11. |
| Workaround |
Restart the database to free the leaked memory in appshrh. |
| 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.1.0.11
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.11
|
 |
