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
|
Memory is allocated for each instance of the Database Manager at the following times:
Once a database is already in use by one application, any subsequent connecting applications will only have agent private memory and application global shared memory allocated on their behalf.
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
 |
The FCM memory requirements are either allocated from the FCM Buffer Pool, or from both the Database Manager Shared Memory and the FCM Buffer Pool, depending on whether or not the partitioned database system uses multiple logical nodes. See the following description of the FCM Buffer Pool for details.
Figure 85. FCM Buffer Pool when Multiple Logical Nodes Are Not Used
 |
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
 |
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).
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.
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.