Maybe it is related to our other Problem "[389-devel] Re: Locking Problem when deleting in parallel" in a way that IO Bottlenecks causing the caching to malloc and retry over and over? Just a theory...

On 17.11.23 11:56, Thierry Bordaz wrote:

So previous tuning was

How large was it ? How many nsslapd-threadnumber ?


nsslapd-threadnumber: 128


if with caches reduced by 10 times (130Mb, 3* 13Mb) it remains stable that means there are no leak. But caches are very small. What is the available memory  on the box ?


The machine has 32 GB memory, so the values prefixed with a minus above should easyly fit.(see below)

best regards
Theirry

On 11/16/23 20:19, Harald Strack wrote:

Hi,

caches where in autosizing mode, this seems not to work in our case (?)

grep nsslapd-cache-autosize /etc/dirsrv/slapd-ldap1/dse.ldif
nsslapd-cache-autosize: 10
nsslapd-cache-autosize-split: 40

Only when we set


nsslapd-cache-autosize: 0

and reduce all cashes by a factor of about 10 and 100 (see below):


@@ -1521,11 +1521,11 @@
 numSubordinates: 4
 nsslapd-suffix: cn=changelog
 nsslapd-cachesize: -1
-nsslapd-cachememsize: 671088640
+nsslapd-cachememsize: 67108864
 nsslapd-readonly: off
 nsslapd-require-index: off
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db/changelog
-nsslapd-dncachememsize: 134217728
+nsslapd-dncachememsize: 13421772
 
 dn: cn=config,cn=ldbm database,cn=plugins,cn=config
 objectClass: top
@@ -1539,7 +1539,7 @@
 nsslapd-mode: 600
 nsslapd-idlistscanlimit: 4000
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db
-nsslapd-dbcachesize: 1342657822
+nsslapd-dbcachesize: 13426578
 nsslapd-db-logdirectory: /var/lib/dirsrv/slapd-ldap1/db
 nsslapd-db-durable-transaction: on
 nsslapd-db-transaction-wait: off
@@ -1586,7 +1586,7 @@
 numSubordinates: 4
 nsslapd-suffix: o=netscaperoot
 nsslapd-cachesize: -1
-nsslapd-cachememsize: 671088640
+nsslapd-cachememsize: 67108864
 nsslapd-readonly: off
 nsslapd-require-index: off
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db/NetscapeRoot
@@ -1600,11 +1600,11 @@
 numSubordinates: 10
 nsslapd-suffix: dc=fhm,dc=edu
 nsslapd-cachesize: -1
-nsslapd-cachememsize: 671088640
+nsslapd-cachememsize: 67108864
 nsslapd-readonly: off
 nsslapd-require-index: off
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db/userRoot
-nsslapd-dncachememsize: 134217728
+nsslapd-dncachememsize: 13421772

the memory consumption keeps stable. The machine has 32 GB memory, so the values prefixed with a minus above should easyly fit.

On 13.11.23 13:22, Thierry Bordaz wrote:

Hi,

389 1.3.11-1-3 is the latest version on that branch and is quite widely installed. So far we are not informed of memory leaks on that release. If cache tuning are reasonable vs available memory and you suspect a leak, I would suggest to use valgrind and the suspected unindexed search.

best regards
thierry

-- 
Harald Strack
Geschäftsführer

ssystems GmbH
Kastanienallee 74
10435 Berlin

--
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-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-devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


--
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-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-devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

-- 
Harald Strack
Geschäftsführer

ssystems GmbH
Kastanienallee 74
10435 Berlin