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,

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:


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


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


As Germane said, there is work to reduce the impace of memory
fragmentation on process memory size, so these are hopefully temporary


William Brown
Software Engineer
Red Hat, Brisbane

389 users mailing list