The process
of tuning an ESE DB2 database is almost automatic, at least according to the
DB2 manuals and Web announcements. However, much of this tuning still requires
human intervention. The Fast Communication Manager is one of the components
that need hand tuning. FCM is used to control the information flow between
database partitions as well as to manage optimal performance for shared nothing
architecture. IBM is keeping the details for the FCM interconnection interface
under cover as much as possible, with the intention to make it self managed in
the future. However, version 8.1 still requires some configuration. In this article,
I will explain the global DB2 memory structure and FCM tuning parameters for a SUN
Solaris platform.
This article covers:
-
DB2 Memory
Model -
DBM Instance
Memory Structure -
Fast
Communication Manager (FCM) - Conclusion
DB2 Memory Model
The DB2 memory model has the following main components:
Database Manager Instance Memory (DBM Shared Memory) is the database manager’s (DBM) allocated
memory, and is used for the DB2 data structures manipulation and instance
activity handling. Information regarding database instance memory handling is
hard to find. DB2 version 7.2 has no ability to control instance memory
allocation, while there exists in DB2 version 8.1 a new DBM configuration
parameter instance_memory for defining suitable instance memory
allocation:
Parameter |
Configurable |
Automatic |
instance_memory |
No |
Yes |
The range
of values for the DBM instance memory allocation are between 32 KB and 2GB or
between 8 and 524 288 4K pages.
# db2 get db cfg | grep DATABASE_MEMORY
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC
By
default, DB2 will automatically (AUTOMATIC) adjust instance memory allocation to
reflect current resource requirements. The allocated, internally calculated memory
will be acquired on instance activation and freed on instance deactivation.
Database Global Memory (DB Shared Memory) is the database allocated memory
area used by all applications connected to the same database. DB global memory
is allocated on database activation and cleared on database deactivation.
Several shared, dynamically tunable areas build global memory. Included memory areas
are buffer pools, lock list, database and utility heap, package cache, and
catalog cache. Additionally, each database in the instance has a private global
memory block. The minimum reserved, per database shared memory allocation is
defined with the DBM parameter database_memory.
Parameter |
Configurable |
Automatic |
database_memory |
No |
Yes |
The range
of values for the DB database memory allocation are between 0 KB and 16TB or
between 0 and 4 294 967 295 4K pages.
DB2 will
calculate the necessary memory requirements on database activation and
therefore automatically adjust the database_memory parameter.
# db2 get db cfg | grep DATABASE_MEMORY
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC
The parameter
DATABASE_MEMORY is provided only for DB2 version 8.1 and above.
Application
Memory is the memory
segment used for internal data exchange between the DB2 database and connected
applications. Application memory is global, shared or private and is allocated
on demand. Application memory size is controlled by the defined maximum
concurrent active applications (maxappls) in the database.
# db2 get db cfg | grep MAXAPPLS
Max number of active applications (MAXAPPLS) = 40 –> version 7.2
Max number of active applications (MAXAPPLS) = AUTOMATIC –> version 8.1
DB2
version 7.2 has 40 as a default number of active applications while version 8.1
defaults MAXAPPLS to AUTOMATIC value.
Agent
Private Memory is
an application service memory. This memory is allocated by the database agents serving
connected database applications. The agent private memory includes sort heaps,
cursor information and session context area. Common agent’s memory allocation is
limited by lower values of the DB parameters maxappls and maxagents.
# db2 get dbm cfg | grep MAXAGENTS
Max number of existing agents (MAXAGENTS) = 400