A problem similar to a memory leak has been introduced in the
following levels of code :
10.1 Fix Pack 6 (APAR IT18654)
10.5 Fix Pack 9 (APAR IT18655)
11.1 Mod 1 Fix Pack 1 (APAR IT18656)
11.5 GA
Only DPF environments with long-running transactions are
vulnerable. The memory buildup occurs when an SQL statement is
repeatedly invoked without committing.
On remote nodes only (not the coordinator), memory
allocations associated with the SQL section are freshly
allocated on each invocation instead of being reused. Upon
commit, however, the memory is released (cached for reuse or
freed as part of normal cache fluctuations).
There are several factors that point to this problem being the
source of increased memory usage:
1. The problem occurs after upgrading to the above-mentioned
levels
2. The memory usage is in the "Application Memory" consumer :
db2pd -dbptnmem (ensure to run on remote partitions, eg. -member
)
Name Mem Used (KB) HWM Used (KB) Cached (KB)
========================================================
APPL-TEST 160000 160000 157632
db2 "select * from
table(mon_get_memory_set('APPLICATION','TEST',-2))"
will show increasing values for several columns, including
MEMORY_SET_SIZE
3. The specific memory pool that is increasing in memory usage
is the "Application Shared" (APPL_SHARED) heap :
db2 "select * from
table(mon_get_memory_pool('APPLICATION','TEST',-2)) where
MEMORY_POOL_TYPE='APPL_SHARED'"
In db2pd this is the "appshr" pool in db2pd -db -mempools
output)
4. specific memory blocks increasing are similar to the
following :
db2pd -db -memblocks top appl 20
Top memory consumers in Appl memory set:
PoolID PoolName TotalSize(Bytes) %Bytes TotalCount
%Count LOC File File hash code
20 appshrh 555048 52.37 39
14.39 5063 sqlra_sql_workspace.C 1095929873
20 appshrh 86112 8.12 39
14.39 1193 sqlriSectInit.C 1127556507
20 appshrh 20592 1.94 39
14.39 7550 sqlri_dss.C 930532034
20 appshrh 19968 1.88 39
14.39 1556 sqlriSectInit.C 1127556507
20 appshrh 4992 0.47 39
14.39 2490 sqlra_sql_workspace.C 1095929873
20 appshrh 4680 0.44 39
14.39 1116 sqlriSectInit.C 1127556507
5. Applications are seen with long-running transactions, eg. the
following monitoring statement shows a very high number of
activity requests within a unit of work :
db2 "select uow_id,act_rqsts_total from
table(mon_get_unit_of_work(null,null)) order by act_rqsts_total
desc" |
