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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users