[389-users] DS crashed /killed by OS

[Mark Reynolds]

On 11/01/2015 08:50 PM, William Brown wrote:
> On Thu, 2015-10-22 at 17:48 +0000, Fong, Trevor wrote:
>> Hi German,
>>
>> Thanks for your suggestion.  I’m happy to confirm that setting
>> userRoot’s nsslapd-cachememsize: 429496730 (1/15th of previous value
>> of 6 GB) has addressed the memory issue for now, and % Mem for the ns
>> -slapd process seems to be at a manageable level.
>>
>> Thanks very much,
>> Trev
>>
>>
>>
> As I understand it, the fragmentation is due to the use of fastbins.
> see man mallopt M_MXFAST for an explination.
>
> You may be able to reduce fragmentation with the setting nsslapd-malloc
> -mxfast, but you may see a (potentially severe) degredation in
> performance. As I understand the value is by default 64 on a 32 bit
> system, and 128 on a 64bit one, so perhaps try reducing it by half and
> see if that helps.
>
> I'm not sure if this is a supported option either so you may not wish
> to enable it. You should always try changes like this on a non
> -production system first.
Well we have not seen any significant improvement modifying the fast 
bins(M_MXFAST).  So while it can slightly reduce fragmentation, 
unfortunately it's not really a solution.  Now using a different memory 
allocator, like jemalloc, has shown significant improvements in memory 
size/fragmentation.  Checkout:

http://www.port389.org/docs/389ds/FAQ/jemalloc-testing.html

The only issue is that jemalloc is not available on all platforms 
yet(especially older versions of RHEL/fedora).

Mark
>
> Alternatelly, you can set the cachemem to autosize with nsslapd-cache
> -autosize=50 or something like that. This way the cache will use only
> 50% of the free ram on the system. I believe this value is determined
> at server start up, rather than being constantly adjusted through the
> lifetime of the process.
>
> Remember, that with the caching, there is some good material in the
> tuning guide which may help you understand the correct values you
> should set for your cache sizes based on the number of entries you
> have.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/
> 10/html/Performance_Tuning_Guide/index.html
>
> As Germane said, there is work to reduce the impace of memory
> fragmentation on process memory size, so these are hopefully temporary
> solutions.
>
>> -
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20151102/3ce9cccc/attachment.html>