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
