IBM Support

db2start fails due to enforcement of maximum semaphore arrays on Linux Kernels 3.10.0-1127.el7 and 4.18.0-147.el8_1 and newer

Flashes (Alerts)


Abstract

A db2start, or other operations, might fail due to new kernel enforcement of maximum semaphore arrays starting with kernel versions 3.10.0-1127.el7.x86_64, or kernel version 4.18.0-147.el8_1.x86_64.
(This applies to any linux distribution that uses these kernel levels or newer, such as RHEL 7.8, RHEL 8.1 respectively, but other distributions as well).

Content

Starting with kernel version 3.10.0-1127.el7.x86_64, or kernel version 4.18.0-147.el8_1.x86_64, the maximum number of configurable semaphore arrays is now enforced to 32768. 
This change to the kernel enforcement behavior is described in the following Red Hat Knowledgebase article: https://access.redhat.com/solutions/4968021
On these new kernel versions, a db2start operation, which succeeded in a previous kernel version, might now fail because it is not able to configure semaphore arrays greater than 32768.  Semaphores are used for database inter-process/thread communication, and thus databases with workloads requiring a significant number of agents/EDUs require more semaphores.
When the configured maximum number of kernel semaphores arrays (kernel.sem SEMMNI) is less than the minimum value required by Db2 (as documented in Kernel parameter requirements (Linux)), then db2start will attempt to automatically increase the maximum number of semaphore arrays to 256*(size of RAM in GB). This means when 128GB of RAM, or greater exists, Db2 will not be able to configure greater than 32768 semaphore arrays.
db2start will then proceed with the currently configured kernel maximum number of semaphore arrays (kernel.sem SEMMNI) in place, however if this value is low (such as the kernel default 128), then db2start may fail to allocate sufficient semaphores for database startup, and the following entry will appear in the db2diag.log:
2020-04-14-01.23.06.849143-420 E42143E400            LEVEL: Error (OS)
PID     : <pid>                TID : <tid> PROC : db2sysc 0
INSTANCE: <instname>              NODE : 000
HOSTNAME: <hostname>
FUNCTION: DB2 UDB, oper system services, sqlo_waitlist::initialize, probe:10
MESSAGE : ZRC=0x8300001C=-2097151972
CALLED  : OS, -, semget                           OSERR: ENOSPC (28)
2020-04-14-11.16.14.698368-420 E72551E480 LEVEL: Severe
PID : <pid>  TID : <tid> PROC : db2sysc 0
INSTANCE: <instname> NODE : 000
HOSTNAME: <hostname>
FUNCTION: DB2 UDB, oper system services, sqloEDUEntry, probe:10
CALLED : DB2 UDB, oper system services, sqloGetShrEDUWaitElem
RETCODE : ZRC=0x850F0081=-2062614399=SQLO_SSEM_EXCEED_MAX
"Requesting too many semaphores"
DIA8336C Requested too many semaphores.
Alternately, if the currently configured kernel for the maximum number of semaphore arrays (kernel.sem SEMMNI) is sufficient for db2start to succeed, Db2 may fail later on if the database workload necessitates an increase in the number of agents/EDUs, and more semaphore arrays are required and exceeds the maximum.
You can use 'ipcs -l' to examine the 'max number of arrays':
$  ipcs -l

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 256000
max ops per semop call = 32
semaphore max value = 32767
To work around this issue, either:

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[],"Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
26 September 2022

UID

ibm10735121

Page Feedback