On DB2 10.5 Fix Pack 4, DB2 memory management metadata is leaked
on non-coordinator members due to a logic problem when using
both query intra-parallelism and DPF (Database Partitioning
Feature). This memory is leaked in the database memory set per
query for many common types of SQL execution. Query
intra_parallelism is typically being used when INTRA_PARALLEL =
YES, but can also be dynamically enabled through other methods.
The easiest way to determine the leak is occurring is by
checking for a build up of Shared Sort memory subpools on the
non-coordinator members. Log into a machine where a
non-coordinator member resides, and find the total count of
these subpools:
export DB2NODE=<member>
db2pd -db <database> -mempools subpool | grep sort | grep
subpool | wc -l
This number should not greatly exceed the number of agents on
the member.
The approximate amount of memory leakage can be determined by
performing the following query for a given member. If
memory_set_used greatly exceeds memory_pool_used, it is highly
likely caused by the product defect addressed in this APAR.
For example:
db2 select memory_set_used from
table"(mon_get_memory_set('DATABASE','SAMPLEDB',1))"
MEMORY_SET_USED
--------------------
188672
db2 select sum"(memory_pool_used)" as memory_pool_used from
table"(mon_get_memory_pool('DATABASE','SAMPLEDB',1))"
MEMORY_POOL_USED
--------------------
184704
Note that this difference of approximately 4MB is minor and
would not be a concern. A difference of 100MB or more would be a
concern and the applicability of this APAR should be further
evaluated. However, as stated, any DPF environment using query
parallelism will encounter the leak, and should apply the
workaround or contact support for a temporary fix. |
