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@xxxxxx> > To: "General discussion list for the 389 Directory server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, October 20, 2015 7:09:46 PM > Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxxxx on behalf > of German Parente" <389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx on behalf of > gparente@xxxxxxxxxx> 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@xxxxxxxxxxx> > >> To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > >> Sent: Wednesday, February 4, 2015 8:50:55 PM > >> Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxxxx > >> https://admin.fedoraproject.org/mailman/listinfo/389-users > >-- > >389 users mailing list > >389-users@xxxxxxxxxxxxxxxxxxxxxxx > >https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
