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

Reply via email to