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
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
Red Hat, Brisbane
389 users mailing list