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
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
