On 4/21/23 2:18 PM, Nazarenko, Alexander wrote:

Hi, Thierry,

Where can I see the relation between 389 DS 7.9.* versions and 1.3.* versions of 389-ds-base to keep track of the expected changes?

This is comparing upstream verses downstream.  It's not so straightforward:

Downstream (search for 389-ds-base) on https://brewweb.engineering.redhat.com/brew/

For example; https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=2386883

Upstream you can do git log on the 1.3.x tags:

$ git clone https://github.com/389ds/389-ds-base.git ; cd 389-ds-base

$ git checkout 389-ds-base-1.3.11.1

$ git log --oneline


HTH,
Mark




Thank you,

- 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 3:36 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,

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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=cVczr8Dfyui60txfEX3PQi22OpsRX9x9_26Ocpvir-U&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=Qb6moHqCALNzHsUVhRWWwA_v5MiLdLFio2T3DzrPPxg&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=pQ65LCATfGAb6fkaeBzPlxzn7HBNFYJXeT2wCUtwrgc&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]> 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]
        To unsubscribe send an email to
        [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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=g5SN0FtjYsArHtitOyspKERV5acf16K9E2tZHPowT58&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=rMifDFHItINAcxL67b7PH-No8b2SqbZ-dtXrlWwmPdg&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=DYfnGKiEMCTuxgJKy7ALpUfQSG8l8DK4onUFBoVJBCU&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=a6Y-uc-fArhcNYCwmx0Qv4ZBvK2aRrflPNnAF6txnVg&e=>

--
    ---------------------------------------------
    Casey Feskens <[email protected]>
    Director of Infrastructure Services
    Willamette Integrated Technology Services
    Willamette University, Salem, OR
    Phone:  (503) 370-6950
    ---------------------------------------------



    _______________________________________________

    389-users mailing list [email protected]

    To unsubscribe send an email [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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=g5SN0FtjYsArHtitOyspKERV5acf16K9E2tZHPowT58&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=rMifDFHItINAcxL67b7PH-No8b2SqbZ-dtXrlWwmPdg&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=DYfnGKiEMCTuxgJKy7ALpUfQSG8l8DK4onUFBoVJBCU&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=L8I6tptCD6vpEO6wL9Wr1GAH1vrc-ntl1v0Yv3ZkeDhnYN9G4X7dKyatoHufsvhj&s=a6Y-uc-fArhcNYCwmx0Qv4ZBvK2aRrflPNnAF6txnVg&e=>


_______________________________________________
389-users mailing list [email protected]
To unsubscribe send an email [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

--
Directory Server Development Team
_______________________________________________
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