[389-users] DS crashed /killed by OS

German Parente gparente at redhat.com
Tue Oct 20 17:23:08 UTC 2015


Hi Trevor,

no problem. In fact, this issue has been investigated by the experts and it's due to fragmentation. A fix is being tested right internally but not delivered yet, to use a different allocator.

The official workaround is different to the one I have proposed. It's finally to define entry cache rather small since the fragmentation could be like 

15 * size of entry cache.

So, we need something like (15 * size of entry cache )  <  Available memory.

Thanks and regards,

German.



----- Original Message -----
> From: "Trevor Fong" <trevor.fong at ubc.ca>
> To: "General discussion list for the 389 Directory server project." <389-users at lists.fedoraproject.org>
> Sent: Tuesday, October 20, 2015 7:09:46 PM
> Subject: Re: [389-users] DS crashed /killed by OS
> 
> Hi German,
> 
> Apologies for resurrecting an old thread.
> We're also experiencing something similar.  We're currently running
> 389-ds-base-1.2.11.15-48.el6_6.x86_64
> 
> I'm afraid I don't have login privileges in order to view the details of the
> bug you linked.
> Could you please post details of how you defined an entry cache to include
> the whole db, and why this works?
> 
> FYI - moves are afoot re upgrading DS on a set of new servers, but in the
> meantime, we need to address this issue.
> 
> 
> Thanks a lot,
> Trev
> 
> 
> 
> 
> 
> On 2015-02-05, 1:57 AM, "389-users-bounces at lists.fedoraproject.org on behalf
> of German Parente" <389-users-bounces at lists.fedoraproject.org on behalf of
> gparente at redhat.com> wrote:
> 
> >
> >Hi,
> >
> >we have had several customer cases showing this behavior. In one of these
> >cases, we have confirmed it was due to memory fragmentation after
> >cache-trashing.
> >
> >We have stopped seeing this behavior by defining an entry cache which
> >includes the whole db (when possible, of course).
> >
> >Details can be found at:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1186512
> >Apparent memory leak in ns-slapd; OOM-Killer invoked
> >
> >Regards,
> >
> >German
> >
> >----- Original Message -----
> >> From: "David Boreham" <david_list at boreham.org>
> >> To: 389-users at lists.fedoraproject.org
> >> Sent: Wednesday, February 4, 2015 8:50:55 PM
> >> Subject: Re: [389-users] DS crashed /killed by OS
> >> 
> >> On 2/4/2015 11:20 AM, ghiureai wrote:
> >> 
> >> 
> >> 
> >> Out of memory: Kill process 2090 (ns-slapd) score 954 or sacrifice child
> >> 
> >> It wasn't clear to me from your post whether you already have a good
> >> understanding of the OOM killer behavior in the kernel.
> >> On the chance that you're not yet familiar with its ways, suggest reading,
> >> for example this article :
> >> http://unix.stackexchange.com/questions/153585/how-oom-killer-decides-which-process-to-kill-first
> >> I mention this because it may not be the DS that is the problem (not
> >> saying
> >> that it absolutely is not, but it might not be).
> >> The OMM killer picks a process that is using a large amount of memory, and
> >> kills it in order to preserve system stability.
> >> This does not necessarily imply that the process it kills is the process
> >> that
> >> is causing the system to run out of memory.
> >> You said that the DS "crashed", but in fact the kernel killed it -- not
> >> quite
> >> the same thing!
> >> 
> >> It is also possible that the system has insufficient memory for the
> >> processes
> >> it is running, DS cache size and so on.
> >> Certainly it is worthwhile checking that the DS hasn't been inadvertently
> >> configured to use more peak memory than the machine has available.
> >> 
> >> Bottom line : there are a few potential explanations, including but not
> >> limited to a memory leak in the DS process.
> >> Some analysis will be needed to identify the cause. As a precaution, if
> >> you
> >> can -- configure more swap space on the box.
> >> This will allow more runway before the kernel starts looking for processes
> >> to
> >> kill, and hence more time to figure out what's using memory and why.
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> --
> >> 389 users mailing list
> >> 389-users at lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >--
> >389 users mailing list
> >389-users at lists.fedoraproject.org
> >https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users


More information about the 389-users mailing list