If you have the ability to do so and your kernel is v5+, out-of-hours experiment with disabling system swap entirely (vm.swapiness=0 and 'swapoff -a' ) and then simulate a run of requests you'd expect to encounter the page errors with and see if it stops happening.
Depending on what else is going on this might not be a production-compatible strategy, but it will either rule that out as a potential flaw/bug in 2.5 and/or give you a workaround until it's fixed.
________________________________ From: Paul B. Henson henson@acm.org Sent: 26 July 2022 00:16 To: openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: dynlist vs memberof performance issues
On 7/25/2022 10:38 AM, Shawn McKinney wrote:
As you (and others) have pointed out, there's a significant performance penalty for searching attributes generated by dylist.
I'm still seeing performance issues with queries that simply return memberOf, with no reference to it in the actual search filter.
For example, this query which searches on the static uid attribute and returns memberOf:
time ldapsearch -H ldapi:/// uid=henson memberOf
Most of the time it completes in fractions of a second:
real 0m0.187s user 0m0.005s sys 0m0.003s
But sometimes it takes 5 seconds, 10 seconds, or even more. These extremely slow response times coordinate with a high read I/O percentage on the server and the high number of page faults on the slapd process.
When I first deployed 2.5, sometimes the server would get into a state where every query that requested memberOf would take in excess of 30 seconds to return until the server was restarted. I cranked up the memory on the servers and at this point I have had no more reoccurrences of that behavior, but I am still regularly seeing occasional slow performance on the queries and high read I/O percentages.
The servers have way more memory now than they should need to fully cache the entire database:
# du -sh /var/symas/openldap-data-cpp 2.6G /var/symas/openldap-data-cpp
# free -m total used free shared buff/cache available Mem: 4818 703 124 0 3991 3831 Swap: 2047 136 1911
I haven't been able to correlate the slow response times with any other external criteria such as updates or query load. Sometimes it's just slow 8-/. We never saw this problem under 2.4 which used the previous implementation of dynlist to generate memberOf. I definitely appreciate the ability to query on dynamic memberOf that was added in 2.5, but it would be nice to sort out this performance issue.
********** Internet Email Confidentiality Footer **********
Privileged/Confidential information may be contained in this message. If you have received this message in error you should, without taking any copies, immediately delete it from your system and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. All contracts for goods and services are subject to the terms and conditions of our relevant company, a copy of which is available on request or by visiting the company’s website.
Amari Metals Ltd. Registered in England and Wales number 2023155. Registered Office: Parkway House, Unit 6, Parkway Industrial Estate, Pacific Avenue, Wednesbury, WS10 7WP.