[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Slapd is coming down



Hello quanah!
Yes, I know, my SO killed the slapd because it was configured.
But I don't have any other service in the server, only the openldap.

Quanah, below follow the information:
- Openldap-syncrepl: 2 GB
- Openldap-translucent: 567 MB
Now, about the slapd process. The strange is the size in the memory:
- Server 1
Tasks: 110 total,   1 running, 109 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.3%sy,  0.0%ni, 99.2%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  12248128k total,  5686580k used,  6561548k free,   223244k buffers
Swap:  2097148k total,    88940k used,  2008208k free,  4488408k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                           
4965 ldap      20   0 4692m 777m 527m S  1.0  6.5 101:16.12 slapd                                                                             
1460 ldap      20   0 9700m 2.1g 1.9g S  0.3 18.0   1174:58 slapd 

ldap      1460     1  2 Jul12 ?        19:34:58 /usr/local/openldap/libexec/slapd -h ldap://127.0.0.1:1389 ldaps://127.0.0.1:1636 -f /usr/local/openldap/etc/openldap/slapd-syncrepl.conf -u ldap -g ldap -l local3
ldap      4965     1 10 Aug19 ?        01:41:19 /usr/local/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /usr/local/openldap/etc/openldap/slapd.conf -u ldap -g ldap -l local4
root     14399 14157  0 09:12 pts/0    00:00:00 grep ldap

- Server 2
Tasks: 113 total,   1 running, 112 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.7%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  12194476k total,  8111400k used,  4083076k free,   213632k buffers
Swap:  2097148k total,     7344k used,  2089804k free,  7225108k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                           
30907 ldap      20   0 8832m 2.3g 2.2g S  0.0 19.9  11:10.55 slapd                                                                             
30956 ldap      20   0 4486m 502m 339m S  0.0  4.2   7:34.95 slapd

ldap     30907     1  1 Aug19 ?        00:11:10 /usr/local/openldap/libexec/slapd -h ldap://127.0.0.1:1389 ldaps://127.0.0.1:1636 -f /usr/local/openldap/etc/openldap/slapd-syncrepl.conf -u ldap -g ldap -l local3
ldap     30956     1  0 Aug19 ?        00:07:39 /usr/local/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /usr/local/openldap/etc/openldap/slapd.conf -u ldap -g ldap -l local4

Otherwise, in the few days, the slapd process increase the consumption  until remain nothing! And it is the why the oom-killer kill the slapd, because your bad score.
Why is the slapd consuming many memory?

Do you need more information?

Thank you!

Em 19/08/2015 14:11, "Quanah Gibson-Mount" <quanah@zimbra.com> escreveu:
--On Wednesday, August 19, 2015 2:39 PM -0300 Édnei Rodrigues <ednei.felipe.rodrigues@gmail.com> wrote:


Hello Guys, how are you doing ?

Aug 19 09:51:44 ds1openldap2h kernel: Out of memory: Kill process 21760
(slapd) score 957 or sacrifice child
Aug 19 09:51:44 ds1openldap2h kernel: Killed process 21760, UID 55,
(slapd) total-vm:18314360kB, anon-rss:11646816kB, file-rss:680kB

Your OS killed it, slapd didn't "come down".  You don't give any useful information, so it's hard to provide guidance.  I've often seen this when other processes (particularly java based) are using up memory, and slapd goes to alloc new memory, so the OS kills it.  Useful details besides your version (2.4.39, per the log) would be:

database backend
database size
slapd process size after DB is fully in memory

etc

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration