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 <[email protected]> wrote: > --On Wednesday, June 13, 2018 11:30 PM +0200 Saurabh Lahoti > <[email protected]> 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> > >
