IBM Books

Administration Guide


How DB2 Uses Memory

Many of the configuration parameters available in DB2 affect memory usage on the system. Some may affect memory on the server, some on the client, and some on both. Furthermore, memory is allocated and de-allocated at different times and from different areas of the system.

A system administrator should also take into consideration balancing overall memory usage on the system. Different applications running on the operating system may use memory in different ways. For example, some applications may use the file system cache, while the Database Manager uses its own buffer pool for data caching instead of the operating system facility. See Setting Parameters That Affect Memory Usage for additional considerations.

Figure 83 shows that the Database Manager uses different types of memory.

Figure 83. Types of memory used by the Database Manager


SQLD0RAM


Memory is allocated for each instance of the Database Manager at the following times:

Figure 83 shows how configuration parameter settings can affect memory. In particular, the parameters in the following list can limit the amount of memory that is allocated for specific purposes. (In a partitioned database environment, this memory is required on every database partition.)

Figure 84 summarizes how much memory is used to support applications. The following configuration parameters allow you to control the size of this memory, by limiting the number of "memory segments" (portions of logical memory) and their size.

Figure 84. How Memory Is Used by the Database Manager


SQLD0MEM


Database Manager Shared Memory
Memory space is required for the database manager to run. This space can be very large, especially in intra-partition and inter-partition parallelism environments. You can predict and control the size of this space by reviewing the following sections:

FCM Buffer Pool
If you have a partitioned database system that does not have multiple logical nodes, the Database Manager Shared Memory and FCM Buffer Pool are as shown in Figure 85.

Figure 85. FCM Buffer Pool when Multiple Logical Nodes Are Not Used


SQLD0MM1


If you have a partitioned database system that uses multiple logical nodes, the Database Manager Shared Memory and FCM Buffer Pool are as shown in Figure 86.

Figure 86. FCM Buffer Pool when Multiple Logical Nodes Are Used


SQLD0MEM


Database Global Memory
Database Global Memory is affected by the following configuration parameters:

Application Global Memory
Application Global Memory is affected by the following configuration parameter:

For parallel systems, space is also required for the application control heap, which is shared between the agents that are working on behalf of the same application at one database partition. The heap is allocated when the first agent to receive a request from the application requests a connection. The agent can be either a coordinating agent or a subagent (see Database Agents).

Agent Private Memory

Agent/Application Shared Memory

Setting Parameters That Affect Memory Usage

Parameters that allocate memory should never be set at their highest values, even on systems with the maximum amount of memory installed, unless such a value has been carefully justified. Many of the parameters can allow the Database Manager to very easily and quickly take up all of the available memory on a machine. In addition, the management of a large amount of memory can take significant additional work on the part of the Database Manager and thus incur even more overhead.

Some UNIX-based operating systems allocate swap space when a process allocates memory and not when it is paged out to swap space. In these cases, you should ensure the total shared memory size is backed with the equivalent amount of paging space.

For most of the configuration parameters, memory is only committed as it is required. These parameters reflect the maximum size of a particular memory heap. The notable exceptions to this rule are the following parameters for which memory is fully committed based on the parameter value:

The appropriate values for these types of parameters can best be determined by benchmarking, where typical and worst-case SQL statements are run against the server and the values of the parameters are modified until the point of diminishing return for performance is found. If performance versus parameter values were graphed, the point where the curve begins to plateau or decline would indicate the point at which additional allocation provides no additional value to the application and is therefore simply wasting memory. (See Chapter 27, Benchmark Testing.)

The upper limits of memory allocation for several parameters may be beyond the memory capabilities of existing hardware and operating systems. These limits were chosen to allow for future growth.

For valid parameter ranges, see the parameter descriptions in Chapter 28, Configuring DB2.

FCM Requirements

Start with default values when configuring the following Fast Communications Manager (FCM) configuration parameters:

To tune these parameters, use the database system monitor to monitor the low water mark for the free buffers, free message anchors, free connection entries, and the free request blocks. If the low water mark is less than 10 percent of the number of the corresponding free data item, increase the value of the corresponding parameter. For information on the database system monitor, see Using the Database System Monitor.

Refer to Administration Guide, Design and Implementation for information on enabling FCM communications.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]