DB2 Version 10.1 for Linux, UNIX, and Windows

Kernel parameter requirements (Linux)

The database manager uses a formula to automatically adjust kernel parameter settings and eliminate the need for manual updates to these settings.

Interprocess communication kernel parameters

When instances are started, if an interprocess communication (IPC) kernel parameter is below the enforced minimum value, the database manager updates it to enforced minimum value. The IPC kernel parameter values changed when a DB2® instance is started do not persist when the system is rebooted. After a reboot, kernel settings can be lower than the enforced values until a DB2 instance is started. By adjusting any kernel parameter settings, the database manger prevents unnecessary resource errors.

Table 1. Enforced minimum settings for Linux interprocess communication kernel parameters
IPC kernel parameter	Enforced minimum setting
kernel.shmmni (SHMMNI)	256 * `<size of RAM in GB>`
kernel.shmmax (SHMMAX)	`<size of RAM in bytes>`¹
kernel.shmall (SHMALL)	2 * `<size of RAM in the default system page size>`²
kernel.sem (SEMMNI)	256 * `<size of RAM in GB>`
kernel.sem (SEMMSL)	250
kernel.sem (SEMMNS)	256 000
kernel.sem (SEMOPM)	32
kernel.msgmni (MSGMNI)	1 024 * `<size of RAM in GB>`
kernel.msgmax (MSGMAX)	65 536
kernel.msgmnb (MSGMNB)	65 536 ³
On 32-bit Linux operating systems, the enforced minimum setting for SHMMAX is limited to 4 294 967 295 bytes. SHMALL limits the total amount of virtual shared memory that can be allocated on a system. Each DB2 data server efficiently manages the amount of system memory it consumes, also know as committed memory. The DB2 data server allocates more virtual memory than it commits to support memory preallocation and dynamic memory management. Memory preallocation benefits performance. Dynamic memory management is the process of growing and shrinking real memory usage within separate virtual shared memory areas. To support memory preallocation and dynamic memory management effectively data servers frequently have to allocate more virtual shared memory on a system than the amount of physical RAM. The kernel requires this value as a number of pages. Load performance might benefit from a larger message queue size limit, specified in bytes by MSGMNB. You can view message queue usage can by running the `ipcs -q` command. If the message queues are at capacity, or reaching capacity, during load operations, consider increasing the number of bytes the message queue size limit.

Other recommended kernel parameter settings

Other recommended kernel parameter settings are listed in the following table.

Table 2. Configuring other Linux kernel parameters
Recommended kernel parameter setting	Configuring the kernel parameters for DB2 data server
vm.swappiness=0	This parameter defines how prone the kernel is to swapping application memory out of physical random access memory (RAM). The default setting is `vm.swappiness=60`. The recommended kernel parameter setting, `vm.swappiness=0`, configures the kernel to give preference to keeping application memory in RAM instead of assigning more memory for file caching. This setting avoids unnecessary paging and excessive use of swap space. This setting is especially important for data servers configured to use the self-tuning memory manager (STMM).
vm.overcommit_memory=0	This parameter influences how much virtual memory the kernel permits allocating. The default setting, `vm.overcommit_memory=0`, sets the kernel to disallow individual processes from making excessively large allocations, however the total allocated virtual memory is unlimited. Having unlimited virtual memory is important for DB2 data servers, which retain additional unused virtual memory allocations for dynamic memory management. Unreferenced allocated memory is not backed by RAM or paging space on Linux systems. Avoid setting `vm.overcommit_memory=2`, as this setting limits the total amount of virtual memory that can be allocated, which can result in unexpected errors.