Looks like you ran out of memory on the system(possibly a Directory Server memory leak?) Was there anything in the Directory Server errors log?

What version of 389 are you using? rpm -qa | grep 389-ds-base

You should monitor the 389 process and see if it continues to grow day after day. Now, when you first start up the server it will take a while until all the caches are filled, etc. So the memory will grow at first, but then it should level off and not grow significantly. There is always memory fragmentation, so the process will grow in size, but it should be very minimal. If the process size does continue to grow(significantly), then we will ask you to run the server under valgrind to gather memory leak debug info.

To speed up the cache being fully primed you can do something like this on all the suffixes you have configured:

ldapsearch -D "cn=directory manager" -W -b "<your suffix>" objectclass=top > /dev/null

Mark

On 02/04/2015 01:20 PM, ghiureai wrote:

Hi List,
After succesfully running with 389-DS in production for 3 months , we had DS crashed this am , see OS errorlog for details, there are no erros in DS . I would like to know if there are any DS cfg for memory garbage collection etc
my OS :Linux 2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

Out of memory: Kill process 2090 (ns-slapd) score 954 or sacrifice child
Feb 3 04:53:12 proc5-01 kernel: Killed process 2090, UID 500, (ns-slapd) total-vm:27657260kB, anon-rss:15313560kB, file-rss:268kB
Pid: 2228, comm: puppetd Not tainted 2.6.32-431.el6.x86_64 #1
Feb 3 04:53:11 proc5-01 kernel: Call Trace:
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff810d05b1>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81122960>] ? dump_header+0x90/0x1b0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8122798c>] ? security_real_capable_noaudit+0x3c/0x70
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81122de2>] ? oom_kill_process+0x82/0x2a0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81122d21>] ? select_bad_process+0xe1/0x120
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81123220>] ? out_of_memory+0x220/0x3c0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8112fb3c>] ? __alloc_pages_nodemask+0x8ac/0x8d0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81167b9a>] ? alloc_pages_vma+0x9a/0x150
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114980d>] ? do_wp_page+0xfd/0x920
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114a499>] ? __do_fault+0x469/0x530
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114a82d>] ? handle_pte_fault+0x2cd/0xb00
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8104eeb7>] ? pte_alloc_one+0x37/0x50
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114b28a>] ? handle_mm_fault+0x22a/0x300
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8104a8d8>] ? __do_page_fault+0x138/0x480
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81282571>] ? cpumask_any_but+0x31/0x50
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81150240>] ? unmap_region+0x110/0x130
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114e3ce>] ? remove_vma+0x6e/0x90
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8152a815>] ? page_fault+0x25/0x30
Feb 3 04:53:11 proc5-01 kernel: Mem-Info:
Feb 3 04:53:11 proc5-01 kernel: Node 0 DMA per-cpu:
Feb 3 04:53:11 proc5-01 kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 3 04:53:11 proc5-01 kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 3 04:53:11 proc5-01 kernel: CPU    2: hi:    0, btch:   1 usd:   0
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users