Hi Bob,
The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send.
i.e calling send_all_attrs instead of send_specific_attrs
in the first case it walks the attribute list of the given entry
while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type)
In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent)
75682 objects with 870191 attributes means around 12 attributes per entries
==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them.
so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M
strcasecmp are performed on 25 seconds
Or 2.5 M strcasecmp per seconds
IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck
paging maybe, or other processes spending the bandwidth ?
Regards
Pierre
The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send.
i.e calling send_all_attrs instead of send_specific_attrs
in the first case it walks the attribute list of the given entry
while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type)
In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent)
75682 objects with 870191 attributes means around 12 attributes per entries
==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them.
so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M
strcasecmp are performed on 25 seconds
Or 2.5 M strcasecmp per seconds
IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck
paging maybe, or other processes spending the bandwidth ?
Regards
Pierre
On Fri, May 29, 2026 at 12:49 AM Bob Green via 389-users <389-users@lists.fedoraproject.org> wrote:
On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@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
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
--
389 Directory Server Development Team
389 Directory Server Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
No comments:
Post a Comment