Yes, I haven't gotten to debugging yet, but we are not using PBKDF2-SHA512 and aren't routinely using memberof in our own queries as we aren't currently maintaining much in the way of group memberships in this instance. I do believe that memory growth has happened in line with batch jobs doing large queries.
On Mon, Apr 17, 2023 at 12:38 PM Nazarenko, Alexander < alexander_nazare...@harvard.edu> wrote: > Thank you, Casey, > > > > have you seen the reply by Thierry about probable causes? > > > > *Alexander B. Nazarenko, PhD* > > *IAM Services* | Technology Partner Services > > *Harvard University Information Technology* > > *P**: *617-496-7150* | **M**:* 617-803-3851 > > > > *From: *Casey Feskens <cfesk...@willamette.edu> > *Reply-To: *"General discussion list for the 389 Directory server > project." <389-users@lists.fedoraproject.org> > *Date: *Sunday, April 16, 2023 at 11:39 PM > *To: *"General discussion list for the 389 Directory server project." < > 389-users@lists.fedoraproject.org> > *Subject: *[389-users] Re: 389 DS memory growth > > > > > > 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 < > alexander_nazare...@harvard.edu> 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 -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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=VahkHqwFG118mGcMEtNQ5EabINQr-fub-UhjexRMHVSrL-kDDmdr7MGuaQkFzMBW&s=LISOtgM-5RoIa9CpfJHGcyKVVxyCfu0Scn4iwe7Gpl8&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=VahkHqwFG118mGcMEtNQ5EabINQr-fub-UhjexRMHVSrL-kDDmdr7MGuaQkFzMBW&s=_VPhfFXkMtVPLa4z_oVkDwOSUqTLNYEqlfeNJX5AEhk&e=> > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > <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=VahkHqwFG118mGcMEtNQ5EabINQr-fub-UhjexRMHVSrL-kDDmdr7MGuaQkFzMBW&s=z3VegITLkhxVgpDM88zNqGmKjpLbeVRQX9vvDAqgA_M&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=VahkHqwFG118mGcMEtNQ5EabINQr-fub-UhjexRMHVSrL-kDDmdr7MGuaQkFzMBW&s=DNxG9PzA2v-jLuAYl3qP64wC1OZCs3MGnvVV2N2eZ9Q&e=> > > -- > > --------------------------------------------- > Casey Feskens <cfesk...@willamette.edu> > Director of Infrastructure Services > Willamette Integrated Technology Services > Willamette University, Salem, OR > Phone: (503) 370-6950 > --------------------------------------------- > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@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://pagure.io/fedora-infrastructure/new_issue > -- --------------------------------------------- Casey Feskens <cfesk...@willamette.edu> Director of Infrastructure Services Willamette Integrated Technology Services Willamette University, Salem, OR Phone: (503) 370-6950 ---------------------------------------------
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@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://pagure.io/fedora-infrastructure/new_issue