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.