[389-devel] Re: 389 DS memory growth

[Thierry Bordaz]

Hi,

389 1.3.11-1-3 is the latest version on that branch and is quite widely 
installed. So far we are not informed of memory leaks on that release. 
If cache tuning are reasonable vs available memory and you suspect a 
leak, I would suggest to use valgrind and the suspected unindexed search.

best regards
thierry

On 11/13/23 12:51, Harald Strack wrote:
>  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/[e-mail]...
> > 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
>
>  _______________________________________________
>  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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue