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
<[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/
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
--
---------------------------------------------
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/
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
_______________________________________________
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
