Re: 389 DS memory growth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the update.

I failed to reproduced any significant growth with groups(100)/members(1000) provisioning. The same with searches on person returning 1000 person entries (bound as DM). We will wait for your profiling info.

regards
Theirry

On 4/18/23 18:12, Nazarenko, Alexander wrote:

This is understood, thank you. It is not a big concern for us, as our servers are at least 16Gb.

We are not using pbkdf2 either.

This is the heap growth above 20Gb (and up) that is the concern, due to queries like (objectclass=person) hiting the server.

 

At some point in the near future we plan profile a typical server for memory usage, and plan to keep posted.

 

- Alwes

 

From: Thierry Bordaz <tbordaz@xxxxxxxxxx>
Date: Tuesday, April 18, 2023 at 11:47 AM
To: "General discussion list for the 389 Directory server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx>, "Nazarenko, Alexander" <alexander_nazarenko@xxxxxxxxxxx>
Subject: Re: [389-users] 389 DS memory growth

 

Hi,

Note that the initial memory footprint of an instance 1.3.11 is larger that an 1.3.10 one.

On RHEL 7.9 2Gb VM, an instance 1.3.11 is 1Gb while 1.3.10 is 0.5Gb.
Instances have the same DS tuning.

The difference comes from extra chunks of anonymous memory (heap) that are possibly related to the new rust plugin handling pbkdf2_sha512.

00007ffb0812e000   64328       0       0 -----   [ anon ]
00007ffb0c000000    1204    1060    1060 rw---   [ anon ]
00007ffb0c12d000   64332       0       0 -----   [ anon ]
00007ffb10000000    1028    1028    1028 rw---   [ anon ]
00007ffb10101000   64508       0       0 -----   [ anon ]
00007ffb14000000    1020    1020    1020 rw---   [ anon ]
00007ffb140ff000   64516       0       0 -----   [ anon ]
00007ffb18000000    1024    1024    1024 rw---   [ anon ]
00007ffb18100000   64512       0       0 -----   [ anon ]
00007ffb1c000000    1044    1044    1044 rw---   [ anon ]
00007ffb1c105000   64492       0       0 -----   [ anon ]
00007ffb20000000     540     540     540 rw---   [ anon ]
00007ffb20087000   64996       0       0 -----   [ anon ]
00007ffb271ce000       4       0       0 -----   [ anon ]

This is just the initial memory footprint and does not explain regular growth.
Thanks to progier who raised that point.

regards
thierry

On 4/17/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-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux