Dear,

Firstly, would like to sincerely extend my gratitude for illustrative explanation & clarity on slapd instability problem. Indeed, your correlations with our symptoms truly solves this jigsaw puzzle.

To conclude on this discussion, does OS flavor affects the slapd operations & management.

Earlier we were on Solaris & recently moved to RHEL. And we had ensure exact replica of Solaris is taken into RHEL with CPU, RAM, HDD & other system parameters. On Solaris our LDAP environment was pretty much quiet & stable. It was this migration post which we started encountering memory problem & instability of instances.

Kindly suggest your advice..

----

Thanks & Kind Regards,

Saurabh LAHOTI.

On Wed, 13 Jun 2018 at 22:57, Quanah Gibson-Mount <quanah@symas.com> wrote:

--On Wednesday, June 13, 2018 11:30 PM +0200 Saurabh Lahoti
<saurabh.astronomy@gmail.com> wrote:

> Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd)
> score 888 or sacrifice child
> Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd)
> total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB

This is not slapd crashing. This is linux OOM deciding to kill slapd for
you because your system ran out of memory, and slapd was the last thing to
ask for more memory. The total memory requirements for slapd are not
limited to just what's stored in the database. And, given that you're
using back-bdb or back-hdb, the memory requirements are significantly
higher than the size of the DB, as slapd has to have multiple caches (at
least 3) to help overcome performance issues in BDB (dncache, idlcache,
entrycache).

Add more memory. Better, yet, ensure you are running the latest version of
OpenLDAP and switch to back-mdb, which has significantly smaller memory
requirements than back-bdb/hdb.

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>