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
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,*
On Wed, 13 Jun 2018 at 22:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
--On Wednesday, June 13, 2018 11:30 PM +0200 Saurabh Lahoti
> 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,
Add more memory. Better, yet, ensure you are running the latest version
OpenLDAP and switch to back-mdb, which has significantly smaller memory
requirements than back-bdb/hdb.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: