It's hard to tell. Unindexed searches like this will always hurt performance. Unindexed searches have a tendancy to blow your cache out through evicts/includes. You should check also your db monitor to see if there are many cache evictions. That would tell you that autotuning is too low. We had to develop the cache auto-tune to work with FreeIPA in mind, and so by default it uses 10% of the system ram (25% as of 1.4.4 I think ....). FreeIPA comes with a lot of other daemons like dogtag and co, and they are are memory hungry, so DS has to "share the playground" with them. There were also issues with glibc fragmenting our address space, and that caused us to "appear" to leak (We have since improved this situation of course). When autotuning was added, DS would ship with out of the box, I think 100MB of entry cache only, and some people went to production with this. Auto tuning isn't designed to be perfect, it's designed to be "better than before". And yes we'll keep improving that, but sometimes you need to tweak it to use more of the resources you have for your workload. As yet, I haven't thought of a good way to make it so that a pure 389-ds instance gets more memory, but we tune for less in freeipa to share .... You could find that changing it to 25% or 40% will improve your situation, especially if you are seeing lots of inclusions and evictions. https://access.redhat.com/documentation/en-us/red_hat_directory_server/11... And again, you *really really* should index all the attributes in that query, because any query that is "notes=F|A|U" is going to be bad, and you should configure SSSD to "play nice" ie ignore_group_members=true and enumerate=false to reduce load on your directory servervs, but also to improve your client login times (it used to take 5 minutes for me to sudo at my old workplace until I set ignore_group_members=true). Hope that helps, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs