DB2 10.5 for Linux, UNIX, and Windows

appl_memory - Application Memory configuration parameter

The appl_memory configuration parameter specifies the size of the application memory set. The application memory size counts towards any instance_memory limit in effect.
The appl_memory setting must be large enough to accommodate the concurrent requirements of the following memory pools:
  • The application group shared heap memory pool. This memory pool is a global work area for all applications and is not configurable.
  • The application heap memory pool. This memory pool is configured per application and can be configured by using the applheapsz configuration parameter.
  • The statement heap memory pool. This memory pool is configured per statement compilation and can be configured by using the stmtheap configuration parameter.
  • The statistics heap memory pool. This memory pool is configured per RUNSTATS operation and can be configured by using the stat_heap_sz configuration parameter.
Configuration type
Database
Applies to
  • Database server with local and remote clients
  • Database server with local clients
  • Partitioned database server with local and remote clients
Parameter type
  • Configurable online (requires a database connection)
  • Configurable by member in a DB2® pureScale® environment and in partitioned database environments
Default [range]
Automatic [128 - 4 294 967 295]
  • On 32-bit architectures, the default value is AUTOMATIC with an underlying value of 10000
  • On 64-bit architectures, the default value is AUTOMATIC with an underlying value of 40000
Unit of measure
Pages (4 KB)
When allocated or committed
On Linux and UNIX operating systems
The initial size is allocated on database activation. More memory is allocated as required.
On Windows operating systems
Memory is allocated as required. A minimal amount of application memory is committed on database activation. More memory is committed as required.
When freed
All application memory is freed when a database is deactivated. However, portions of allocated or committed memory are regularly released back to the operating system when these portions of memory are no longer in use.

On UNIX operating systems, after the initial application memory size is allocated during database activation, DB2 allocates more memory as needed to support dynamic memory requirements. Extra memory allocation is subject to any specified fixed size limit. All application memory is allocated as shared memory and is retained until the database deactivates. The total allocated shared memory counts towards only virtual memory usage. While this virtual memory does not require backing by real memory, virtual memory does require backing by swap or paging space on some operating systems. For details about operating system support, see the Operating System Support section.

On Windows operating systems, application memory is allocated as private memory. Application memory allocation is subject to any specified fixed size limit. Memory allocations no longer in use might be freed dynamically or retained for reuse. All outstanding memory allocations are freed when the database deactivates.

Committed memory is memory that is backed by the operating system. Allocated memory is committed as required by memory pools. Committed memory no longer required by memory pools is either cached to improve performance or released to the operating system. Memory is also released or decommitted as necessary if the application memory size is decreased dynamically. All committed memory is released when the database deactivates.

It is recommended to leave appl_memory set to the default of AUTOMATIC. An insufficient fixed application memory setting results in various out of memory failures that are returned to applications. Setting a fixed memory value must be done only after thorough testing to determine peak requirements. Application memory is not tuned by the Self Tuning Memory Manager (STMM), but STMM tunes database_memory, if database_memory is enabled for self-tuning, to compensate for fluctuating application memory requirements.

Operating system support

Table 1. Operating system support
Operating System Available support
AIX Uses medium (64K) pages by default, which can benefit performance. Large (16MB) pages are also allowed on AIX only.1
HP-UX Allocated shared memory requires backing by virtual swap.
Linux Allocated shared memory counts towards the virtual shared memory limit (shmall).
Solaris Allocated shared memory requires backing by virtual swap and counts towards any virtual memory limits.
Windows No additional considerations for the Windows platform.
Note:
  1. The use of large pages (DB2_LARGE_PAGE_MEM) limits DB2's ability to release memory dynamically. It is recommended to configure a fixed appl_memory value when using large page memory.

Monitoring

The application memory set can be monitored through the MON_GET_MEMORY_SET and MON_GET_MEMORY_POOL routines. For example, the following command:
db2 "select member, substr(db_name,1,10)as db_name, substr(memory_set_type,1,10) as set_type, 
memory_set_size, memory_set_committed, memory_set_used, memory_set_used_hwm 
from table(mon_get_memory_set('APPLICATION')"
Returns the following information:
MEMBER DB_NAME    SET_TYPE    MEMORY_SET_SIZE      MEMORY_SET_COMMITTED MEMORY_SET_USED      MEMORY_SET_USED_HWM 
------ ---------- ----------  -------------------- -------------------- -------------------- -------------------- 
     0 SAMPLE     APPLICATION               154927                68616                67829                68616 
     0 TEST       APPLICATION               238092               123404               123404               123404 

  2 record(s) selected.

In this case, the application memory set is using 154927KB of instance_memory(MEMORY_SET_SIZE) and 68616KB of system memory (MEMORY_SET_COMMITTED), of which 67829KB (MEMORY_SET_USED) is assigned to memory pools.

You can also monitor database memory using the db2pd utility: 
 db2pd -db <database_name> -memsets -mempools, db2pd -dbptnmem