Hello Marc, Thanks for this, it took a minute to test this thoroughly but early results are great. Details are below but I tried 5gb dbcachesize and ns-slapd is now using about 50% of memory. I will read deeper on manual tuning but is the general conclusion here that cache auto tuning either isn't reliable in docker or maybe just in 2.x? Regarding version, we are a large educational institution and this is our core authentication platform, we value stability over features: does 3.2.1 make sense to run in production? We tend to prefer to stay a version behind, we want the stable but still supported version. I confirmed THP is disabled and I presume you meant dbcachesize vs cache-memsize though maybe things are different in 3.x, we're (now) on 2.8.0. Here are the settings I'm testing with: morganj@dev-ds-1-app-5:~$ docker exec -it 389ds dsconf localhost backend config get|grep cache nsslapd-import-cachesize: 16777216 nsslapd-dbcachesize: 5000000000 nsslapd-import-cache-autosize: -1 nsslapd-cache-autosize: 0 nsslapd-cache-autosize-split: 25 morganj@dev-ds-1-app-5:~$ and the results after our test run, which, if it's of intersting, is a single run of Google Cloud Directory Sync (GCDS): DB Monitor Report: 2026-07-09 11:41:30 -------------------------------------------------------- Database Cache: - Cache Hit Ratio: 96% - Free Space: 0 B - Free Percentage: 0.0% - RO Page Drops: 0 - Pages In: 349752 - Pages Out: 1521 Normalized DN Cache: - Cache Hit Ratio: 67% - Free Space: 0 B - Free Percentage: 0.0% - DN Count: 124830 - Evictions: 1692281 Backends: - dc=domain,dc=org (userRoot): - Entry Cache Hit Ratio: 35% - Entry Cache Count: 167919 - Entry Cache Free Space: 14.93 KB - Entry Cache Free Percentage: 0.0% - Entry Cache Average Size: 16.39 KB - DN Cache Hit Ratio: 74% - DN Cache Count: 335647 - DN Cache Free Space: 293.5 MB - DN Cache Free Percentage: 91.7% - DN Cache Average Size: 82.0 B total used free shared buff/cache available Mem: 15902 7110 1353 2 7618 8791 Swap: 2559 0 2559 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND morganj 1179397 0.0 0.0 5692 2140 pts/0 S+ 09:55 0:00 tee -a ns-slapd_mem2.out morganj 1412010 0.0 0.0 6544 2472 pts/0 S+ 11:41 0:00 grep -E slap|VSZ root 2808191 6.0 50.9 12506904 8294800 ? Sl Jul08 87:12 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -d 266354688 thank you! -morgan > On Jul 6, 2026, at 08:25, Marc Sauton <msauton@redhat.com> wrote: > > about entry cache use and configuration: > the auto tuning is expected to provide with the most optimized configuration. > but in this case, it may be interesting to try different manual > configuration to change the dynamics in order to eother workaround an > eventual memory leak, or minimize memory fragmentation. > > for example: > > dsconf SOME-INSTANCE-NAME backend config get | grep cache > dsconf SOME-INSTANCE-NAME backend config set --cache-autosize=0 > dsconf SOME-INSTANCE-NAME backend suffix set > --cache-memsize=5000000000 userRoot # example 5 GB for userRoot > dsconf SOME-INSTANCE-NAME backend config get | grep cache > > or with the Cockpit web UI: > https://localhost/389-console > root > password > > Database tab > "Global Database Configuration" > > > about THP, it should be disabled for the ns-slapd process, to verify, try: > grep THP /proc/$(pidof ns-slapd)/status > > > about 389-ds versions: > > per the page at https://www.port389.org/ , the last release is: > 2026-04-29: Released 389-ds-base 3.2.1 > as well as per https://lists.fedoraproject.org/archives/list/389-announce@lists.fedoraproject.org/2026/4/ > https://lists.fedoraproject.org/archives/list/389-announce@lists.fedoraproject.org/thread/ADCDPLPTVSXYSF57UEL7QICWU3UB6MRL/ > Announcing 389 Directory Server 3.2.1 (F45/Rawhide) > and > https://github.com/389ds/389-ds-base/ > ( note there are 3.3 and 3.2.2 for devel ) > > > I can only speak for Fedora, CentOS, and RHEL. I will let others on > this list to comment about Alma, I would expect no issues, but I do > not know the available versions on Alma. > > Cordially, > Marc S. > > > On Fri, Jul 3, 2026 at 1:41 PM Morgan Jones <mjones6@morganjones.org> wrote: >> >> Hello Marc, >> >> Thanks for the quick reply. My responses are inline. >> >>> On Jul 3, 2026, at 05:51, Marc Sauton <msauton@redhat.com> wrote: >>> >>> Hello, >>> The memory increase could be fragmentation. >>> It looks like the entry cache may be too small at around 600MB, you >>> could try tune it up to 1GB or 2GB, up to 5GB, the DB size may be >>> around 5GB. >> >> Well, I had to set auto sizing to 5% to get it to run without crashing so, yeah, the cache is tiny >> >> Do you mean turn off auto sizing and set the entry cache manually? >> >> If I understand you correctly it's a good guess, we're 6gb. Is 16gb of ram not sufficient for a 6gb database? >> >> [root@cb5c999df0ed db]# ls >> DBVERSION __db.001 __db.002 __db.003 log.0000000119 userRoot >> [root@cb5c999df0ed db]# du -sh >> 6.0G . >> [root@cb5c999df0ed db]# du -sh userRoot >> 5.7G userRoot >> [root@cb5c999df0ed db]# >> >> >>> You could also verify if THP is disabled for the LDAP process, >> >> I just read about this last night and it's set to madvise--is that sufficient? I can set to never and test if you're not sure. >> >> [root@cb5c999df0ed /]# cat /sys/kernel/mm/transparent_hugepage/enabled >> always [madvise] never >> [root@cb5c999df0ed /]# >> >>> Note the version 2.7 is from 2025 and there has been a number of >>> serious fixes since then, I would consider to upgrade, add some more >>> recent replicas. >> >> We're still testing so i can switch to any version, I'm trying to stick with whatever is the most current/stable version, is 2.7.0 not the newest 2.x version? Should we be considering 3.x? >> >> And either way is Alma 9 the right base? >> >> thank you! >> >> -morgan >> >>> Thanks, >>> Marc S. >>> >>> On Thu, Jul 2, 2026 at 9:35 PM Morgan Jones via 389-users >>> <389-users@lists.fedoraproject.org> wrote: >>>> >>>> Hello, >>>> >>>> I am struggling to determine why 389-Directory/2.7.0 B2026.064.0000 is using a crippling amount of memory. >>>> >>>> I'm not married to 2.7.0, just looking for something stable and actively supported but not too new. >>>> >>>> We're running it in Docker on almalinux:9. >>>> >>>> If I set nsslapd-cache-autosize to much over 5 ns-slapd consumes memory and is killed by the OOM. I have increased docker's memory limit to that of the host but if it's smaller the same happens, sometimes just sooner as the OOM sees the process exceed Docker's limits. >>>> >>>> The server has 16gb of ram, I have turned off the NDN cache. >>>> >>>> ns-slapd is using 14gb of ram not leaving much for the OS. nsslapd-cache-autosize is set to 5, where is all of the memory going?? >>>> >>>> Here's the current state of the cache: >>>> >>>> # docker exec -it 389ds dsconf localhost monitor dbmon >>>> DB Monitor Report: 2026-07-02 17:24:32 >>>> -------------------------------------------------------- >>>> Database Cache: >>>> - Cache Hit Ratio: 89% >>>> - Free Space: 101.89 MB >>>> - Free Percentage: 51.3% >>>> - RO Page Drops: 14972351 >>>> - Pages In: 15086991 >>>> - Pages Out: 405261 >>>> >>>> Backends: >>>> - dc=domain,dc=org (userRoot): >>>> - Entry Cache Hit Ratio: 13% >>>> - Entry Cache Count: 38259 >>>> - Entry Cache Free Space: 6.8 KB >>>> - Entry Cache Free Percentage: 0.0% >>>> - Entry Cache Average Size: 15.42 KB >>>> - DN Cache Hit Ratio: 97% >>>> - DN Cache Count: 336275 >>>> - DN Cache Free Space: 37.42 MB >>>> - DN Cache Free Percentage: 58.5% >>>> - DN Cache Average Size: 82.0 B >>>> >>>> # >>>> >>>> >>>> Any advice would be appreciated, I have to be missing something simple here! >>>> >>>> Thank you, >>>> >>>> -morgan >>>> -- >>>> _______________________________________________ >>>> 389-users mailing list -- 389-users@lists.fedoraproject.org >>>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org >>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org >>>> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new >>> >> > -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
No comments:
Post a Comment