Tuning SLAPD_OCHANDLERS to handle more connections

Resolving The Problem

The following error might occur in the ibmslapd.log in Windows when too many clients are connecting to the server at the same time:

Feb 11 14:36:04 2084 Communications error: Exceeding 64 connections/OCH - dropping socket.

This happens because there are more incoming requests than the server can handle. To allow the server to handle more incoming requests, the value for SLAPD_OCHANDLERS must be tuned. By default, the server is configured with 10 OCHANDLERS. Each thread can handle 64 simultaneous sockets. As a result, the Windows ibmslapd process can handle 640 simultaneous connections.

To determine the correct number to set for this parameter, estimate the maximum number of expected (simultaneous) incoming connections and divide by 64. If the total number of expected connections is not known, then this value must be adjusted until this error stops occurring.

Here are directions for configuring this variable:

1. Stop the server

2. Save a copy of your ibmslapd.conf.

3. Insert the following line in the section of the ibmslapd.conf that starts with:

dn: cn=FrontEnd,cn=Configuration:

ibm-slapdSetenv: SLAPD_OCHANDLERS=X

where X should be a value greater than 10 (since the default is already 10 and the goal is to allow more connections).

4. Check the ibm-slapdDbConnections value to make sure it's set properly relative to the SLAPD_OCHANDLERS value. See the notes below.

5. Restart the server

Here's an example of the stanza to edit as it normally looks:

dn: cn=Front End, cn=Configuration
cn: Front End
ibm-slapdACLCache: TRUE
ibm-slapdACLCacheSize: 25000
ibm-slapdEntryCacheSize: 25000
ibm-slapdFilterCacheBypassLimit: 100
ibm-slapdFilterCacheSize: 25000
ibm-slapdIdleTimeOut: 300
ibm-slapdSetenv: DB2CODEPAGE=1208
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-SlapdFrontEnd

and how it should look after adding the SLAPD_OCHANDLERS parameter:

dn: cn=Front End, cn=Configuration
cn: Front End
ibm-slapdACLCache: TRUE
ibm-slapdACLCacheSize: 25000
ibm-slapdEntryCacheSize: 25000
ibm-slapdFilterCacheBypassLimit: 100
ibm-slapdFilterCacheSize: 25000
ibm-slapdIdleTimeOut: 300
ibm-slapdSetenv: DB2CODEPAGE=1208
ibm-slapdSetenv: SLAPD_OCHANDLERS=15
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-SlapdFrontEnd

Notes:

The overall limit for available sockets on Win32 systems is 32,000. As a result, the value for SLAPD_OCHANDLERS should never be set larger than 500.

Previous versions of this technote said that the value of SLAPD_OCHANDLERS should always be set to the same number as the ibm-slapdDbConnections value. The reasoning behind that was that you needed enough DB2 threads to handle the amount of activity coming from the incoming connections. However, this is not completely necessary. As long as the server is able to handle all the incoming requests without becoming I/O or CPU bound, then one can experiment with increasing the number of OCHANDLERS without increasing the ibm-slapdDbConnections value. An example where the server can handle many incoming connections without increasing ibm-slapdDbconnections is when the server primarily handles user authentication (ie, binds), which generally take very few system sources.

Despite this, we generally recommend keeping ibm-slapdDbConnections equal to SLAPD_OCHANDLERS unless there's a specific reason not to. Changing these values to be different requires expertise and experience with the SDS/TDS LDAP Server. In addition, whatever SLAPD_OCHANDLERS is set to, we recommend never setting ibm-slapdDbconnections over 50, and almost never more than 40.
It's also important to note that poorly written client applications that do not close their connections to the ldap server can cause the error above and no amount of tuning ofSLAPD_OCHANDLERS will resolve the problem. If the client opens a new connection every time it sends a request to the ldap server and does not close it, the server will soon be exhausted of available connections no matter what SLAPD_OCHANDLERS is set to. You can check for this issue by looking at the output of the 'netstat' command for large numbers of idle TCP connections from the client application.

There is a feature in the SDS/TDS LDAP server that will clean up idle connections in this case. See the technote that describes the reaper functionality. This will help in cases where the client application isn't closing it's connections and can be used in combination with an increased SLAPD_OCHANDLERS value to handle an increased number of incoming connections.