Thank you, Thierry,

the operation that is affecting the memory is a simple query: 
(objectclass=person), which affects every account. This is a standard query we 
used to use daily for a couple of years with no issues, until lately.
The password scheme we use is SSHA512, did not change (I am not seeing 
PBKDF2-SHA512 option via Apache studio).
For 5440, we  use memberof a lot, and with “uniqueMember” and “member” 
membership attributes, it is updated every day on every account.

Shortly I intend use valgrind, as you suggest below.

- Alex

From: Thierry Bordaz <[email protected]>
Reply-To: "General discussion list for the 389 Directory server project." 
<[email protected]>
Date: Monday, April 17, 2023 at 8:43 AM
To: "General discussion list for the 389 Directory server project." 
<[email protected]>, Casey Feskens <[email protected]>
Subject: [389-users] Re: 389 DS memory growth


Hi,

I did some rapid tests around password update  and memory consumption was 
stable.
Did you identify what kind of operation that triggered the growth.
You may use [1] to setup the instance with valgrind

[1] 
https://www.port389.org/docs/389ds/FAQ/faq.html#sts=Debugging%20Memory%20Growth/Invalid%20Access%20with%C2%A0Valgrind<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.port389.org_docs_389ds_FAQ_faq.html-23sts-3DDebugging-2520Memory-2520Growth_Invalid-2520Access-2520with-25C2-25A0Valgrind&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=s9U5tG4HfYQq-dJ-xHztuL1FPNnaFJAHl-YnKnNuE1k&e=>

regards
thierry
On 4/17/23 09:35, Thierry Bordaz wrote:

Hi,

Thanks for raising this issue. Actually the version is an upgrade of 389 7.9.18 
to 7.9.21. It contains only 3 bug fixes

 - 5497: boolean attribute should be case insensitive
 - 5440: memberof can be slow when multiple membership attribute are defined
 - 5565: support of PBKDF2-SHA512 in 7.9

The usual option would be to use valgrind to debug the leak. Because of the 
limited list of bug we can also try to eliminate candidate. I think the first 
one looks safe. For 5440, do you use memberof and with how many membership 
attributes. For 5565, what is your default password storage scheme ? if it is 
PBKDF2-SHA512, could you set it to PBKDF2-SHA256 and monitor memory consumption 
?

[1] 
https://github.com/389ds/389-ds-base/issues/5497<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_389ds_389-2Dds-2Dbase_issues_5497&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=MpwdLaS59UHC-JIiHf6_uCVaKtqqvr-R7drVfv9ax5w&e=>
[2] 
https://github.com/389ds/389-ds-base/issues/5440<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_389ds_389-2Dds-2Dbase_issues_5440&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=ARXK0Rgcfx0-AVGTM_thOxn3E-NQ7l4MOFq6MGAF1Xs&e=>
[3] 
https://github.com/389ds/389-ds-base/issues/5565<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_389ds_389-2Dds-2Dbase_issues_5565&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=8fL_cxRPvq28TAFAhHHcDrj8aWS63qqm91do6xsRqZU&e=>



best regards
thierry
On 4/17/23 05:38, Casey Feskens wrote:

We’ve been experiencing similar memory growth. I’ve had to quadruple RAM on our 
ldap hosts, but things seem stable there. Still unsure what the cause is. Glad 
to hear at least that someone else is seeing the same issue, so I can perhaps 
rule out an environmental change.


On Sun, Apr 16, 2023 at 6:07 PM Nazarenko, Alexander 
<[email protected]<mailto:[email protected]>> wrote:
Hello colleagues,
On March 22nd we updated the 389-ds-base.x86_64 and 389-ds-base-libs.x86_64 
packages on our eight RHEL 7.9 production servers from version 
1.3.10.2-17.el7_9 to version 1.3.11.1-1.el7_9.  We also updated the kernel from 
kernel 3.10.0-1160.80.1.el7.x86_64 to kernel-3.10.0-1160.88.1.el7.x86_64 during 
the same update.
Approximately 12 days later, on April 3rd, all the hosts started exhibiting 
memory growth issues whereby the “slapd” process was using over 90% of the 
available system memory of 32GB, which was NOT happening for a couple of years 
prior to applying any of the available package updates on the systems.

Two of the eight hosts act as Primaries (formerly referred to as masters), 
while 6 of the hosts act as read-only replicas.  Three of the read-only 
replicas are used by our authorization system while the other three read-only 
replicas are used by customer-based applications.

Currently we use system controls to restrict the memory usage.

My question is whether this is something that other users also experience, and 
what is the recommended way to stabilize the DS servers in this type of 
situation?
Thanks,
- Alex


_______________________________________________
389-users mailing list -- 
[email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=AtlXP_1gsj1ESSRu6iB9KtTDO5Xrh8CSsQLcObGpo4I&e=>
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=-b9HgZHFkC0WE94miOFJ3BflSTq4koyFD1dsyi8LxGw&e=>
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_389-2Dusers-40lists.fedoraproject.org&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=L_qNtf4975Z4GPEFWXAFDPtQEos6hQRFrxlkhOJooKU&e=>
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue<https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfrastructure_new-5Fissue&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=1iYbKOMfPs2V2Woc8zDXOWFVdN_caOqB0jWhXixAoNE&e=>
--
---------------------------------------------
Casey Feskens <[email protected]<mailto:[email protected]>>
Director of Infrastructure Services
Willamette Integrated Technology Services
Willamette University, Salem, OR
Phone:  (503) 370-6950
---------------------------------------------



_______________________________________________

389-users mailing list -- 
[email protected]<mailto:[email protected]>

To unsubscribe send an email to 
[email protected]<mailto:[email protected]>

Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=AtlXP_1gsj1ESSRu6iB9KtTDO5Xrh8CSsQLcObGpo4I&e=>

List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=-b9HgZHFkC0WE94miOFJ3BflSTq4koyFD1dsyi8LxGw&e=>

List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_389-2Dusers-40lists.fedoraproject.org&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=L_qNtf4975Z4GPEFWXAFDPtQEos6hQRFrxlkhOJooKU&e=>

Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue<https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfrastructure_new-5Fissue&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=uiyPR4nhbOiFgJxO8FlFxvLTOA66849EeL0Dl9-gcSY&m=lV33tMVSt7aDutaHub0AvhxHB8vvDAY60KCUsK1VnEsU7VGfM8lmeSqHscrn6X7t&s=1iYbKOMfPs2V2Woc8zDXOWFVdN_caOqB0jWhXixAoNE&e=>
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to