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). 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) 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. And yes, requesting specific attrs adds some overhead to the search. Anyway check the access log and your idscanlimit first. Regards, Mark On 5/28/26 4:02 PM, Bob Green via 389-users wrote: > I've been fiddling with various 389ds tuning parameters to see if I > can improve performance running > 389-ds-2.7.0~git144.f597a91d8-150700.3.13.1.x86_64 on SLES15sp7 on a > modestly specced KVM guest with 16GB of RAM and 2 "Intel Core > Processor (Haswell, no TSX)". I believe performance is bottlenecked > by my CPUs. I'm wondering if someone can confirm that an ldapsearch > filter (objectclass=computer) that retrieves 75682 objects with 870191 > attributes counting dn: in just under a minute is considered > reasonable? If instead I request the 77 attributes I want to retrieve > for each object, rather than "attrs=ALL", the same query filter will > take ~85 seconds. I'm guessing the increased time is due to the > overhead incurred by 389ds to selectively pick out those attributes, > and that this is expected? > > I was wondering if there exists any computer sizing recommendations > that might help me determine what hardware I should install 389ds on? > > As mentioned, I believe my 389ds instance is CPU bound, when I run the > same query above in parallel, every additional query seems to add > roughly 30 seconds to the amount of time the queries will take to > finish. e.g. single query finishes in 60 seconds, 2 in parallel 90 > seconds, 4 in parallel ~150 seconds, 10 concurrent queries will take > ~330 seconds for all to complete. sar/mpstat on the 389ds instance > shows that as I increase the number of concurrent queries cpu %usr > utilization on the 389ds increases while %sys drops. expected I'm > guessing... > > I'm trying to rule out whether I have inadequate indexing or whether > some other tunable might improve concurrent queries of what is an > admittedly large query, and hoping the community might be able to > validate that yes, your query is large, if you insist on running this > on 389ds you should plan on having 389ds run on significant hardware > resources. > > Thank you for your time, > Bob -- Identity Management 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