On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol(a)redhat.com> wrote:
>
> Hi Bob,
>
> What is in the access log for these searches? I suspect you're doing an
> unindexed search (check access log for notes=A or notes=U).
There are no notes=A or notes=U access events, just notes=P (paged
search) and a smattering of notes=N.
> This is not really an ideal way to test the server's performance. One
> thing to help with this type of search is to adjust the idscanlimit to
> at least 100000 (it might already be set really high)
>
> # dsconf slapd-YOUR_INSTANCE backend config get | grep
> nsslapd-idlistscanlimit
>
> If it's 4000 (or less than 100k) you can bump it up:
>
> # dsconf slapd-YOUR_INSTANCE backend config set
> --idlistscanlimit=100000 (this does not require a server restart to
> take effect)
nsslapd-idlistscanlimit is 2147483646.
> Otherwise, in this case the only other option is to make sure your entry
> cache is large enough to hold all the entries. Note - running
> concurrent searches like this is not going to be performant because it
> has to process so many results. So I am not surprised the more
> concurrent searches you run the slower they all get.
Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm
database,cn=plugins,cn=config will "automatically size" the entry
cache? I ask because dsconf INSTANCE backend monitor --suffix
dc=example,dc=com reports:
currententrycachesize: 2818570021
maxentrycachesize: 2818572288
which is just about at the maximum, though perhaps this will grow in
size as needed? Or should I replace -1 with a larger value?
I also increased nsslapd-ndn-cache-max-size, dcsonf INSTANCE config
replace nsslapd-ndn-cache-max-size after seeing this with dsconf
INSTANCE monitor backend:
currentnormalizeddncachesize: 20971440
maxnormalizeddncachesize: 20971440
Thank you for the suggestions.
Bob
