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]
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
[2]
https://github.com/389ds/389-ds-base/issues/5440
[3]
https://github.com/389ds/389-ds-base/issues/5565
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
> <alexander_nazarenko(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to
> 389-users-leave(a)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.fedoraproje...
> Do not reply to spam, report it:
>
https://pagure.io/fedora-infrastructure/new_issue
>
> --
> ---------------------------------------------
> Casey Feskens <cfeskens(a)willamette.edu>
> Director of Infrastructure Services
> Willamette Integrated Technology Services
> Willamette University, Salem, OR
> Phone: (503) 370-6950
> ---------------------------------------------
>
> _______________________________________________
> 389-users mailing list --389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to389-users-leave(a)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.fe...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue