Hi,
we experience still the same Problems. The OOM Killer kills the ns-slapd
process regulary.
Versions (CentOS 7)
# rpm -qa | grep 389
389-adminutil-1.1.22-2.el7.x86_64
389-ds-base-libs-1.3.11.1-3.el7_9.x86_64
389-ds-base-devel-1.3.11.1-3.el7_9.x86_64
389-ds-base-1.3.11.1-3.el7_9.x86_64
389-ds-base-snmp-1.3.11.1-3.el7_9.x86_64
389-ds-base-1.3.10.2-8.el7_9.x86_64
389-ds-base-devel-1.3.10.2-8.el7_9.x86_64
389-admin-1.1.46-4.el7.x86_64
389-adminutil-devel-1.1.22-2.el7.x86_64
389-ds-base-libs-1.3.10.2-8.el7_9.x86_64
# uname -r
3.10.0-1160.11.1.el7.x86_64
The behaviour may be related to unindexed searches, since we have
another node that has nearly no unindexed searches and behaves more or
less as usual.
br
Harald
On 17.04.23 03:07, Nazarenko, Alexander 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-devel mailing list --389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to389-devel-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-devel@lists.fe...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
Harald Strack
Geschäftsführer
ssystems GmbH
Kastanienallee 74
10435 Berlin