Hi Trevor,
400Mb could be a more reasonable value. With a cache of 6gb, fragmentation could very
quickly provoke the OOM killer error.
Regards,
German.
----- Original Message -----
From: "Trevor Fong" <trevor.fong(a)ubc.ca>
To: "General discussion list for the 389 Directory server project."
<389-users(a)lists.fedoraproject.org>
Sent: Tuesday, October 20, 2015 7:44:06 PM
Subject: Re: [389-users] DS crashed /killed by OS
Hi German,
Thanks very much for your reply.
Just to make sure I have it straight, I’ve currently got userRoot’s
nsslapd-cachememsize = 6 GB on at 16GB machine.
I should change that to nsslapd-cachememsize = 6 GB / 15 = 429496730
Do I have that right?
Thanks again,
Trev
On 2015-10-20, 10:23 AM, "389-users-bounces(a)lists.fedoraproject.org on behalf
of German Parente" <389-users-bounces(a)lists.fedoraproject.org on behalf of
gparente(a)redhat.com> wrote:
>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(a)ubc.ca>
>> To: "General discussion list for the 389 Directory server project."
>> <389-users(a)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(a)lists.fedoraproject.org on
>> behalf
>> of German Parente" <389-users-bounces(a)lists.fedoraproject.org on behalf
of
>> gparente(a)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(a)boreham.org>
>> >> To: 389-users(a)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-whi...
>> >> 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(a)lists.fedoraproject.org
>> >>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>> >--
>> >389 users mailing list
>> >389-users(a)lists.fedoraproject.org
>> >https://admin.fedoraproject.org/mailman/listinfo/389-users
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>--
>389 users mailing list
>389-users(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users