RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1925621 - document impact of indices and of scope on performance of LDAP queries
Summary: document impact of indices and of scope on performance of LDAP queries
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.4
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Pavel Březina
QA Contact: Steeve Goveas
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-05 17:28 UTC by Antonio Romito
Modified: 2021-11-10 09:08 UTC (History)
10 users (show)

Fixed In Version: sssd-2.5.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-09 19:47:00 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 5603 0 None open document impact of indices and of scope on performance of LDAP queries 2021-04-26 11:18:23 UTC
Red Hat Knowledge Base (Solution) 6043591 0 None None None 2021-07-29 13:47:35 UTC
Red Hat Product Errata RHBA-2021:4435 0 None None None 2021-11-09 19:47:16 UTC

Description Antonio Romito 2021-02-05 17:28:22 UTC 
Description of problem:

The LDAP queries performed with scope=sub can be complex and overload the LDAP server.
For example, SUDO rules LDAP queries performed with scope=sub over a large basedn, could cause an unneeded load.

As a reference of the scope, the customer used:
https://ldapwiki.com/wiki/LDAP%20Search%20Scopes

As changing the sssd scope attribute of the LDAP queries would be disruptive for the running sssd configurations, as the results would change, we would suggest at least to document the fact that for best performance sssd should be set with a smaller scope (eg scope=one).

The customer would recommend considering the switch to scope=one in RHEL9 (or anyway starting with upstream).

Version-Release number of selected component (if applicable):
Any

How reproducible:

Check the documentation

Steps to Reproduce:
1. 
2. 
3.

Actual results:

The documentation does not report that scope=sub could introduce a performance issue

Expected results:

The documentation must report that scope=sub could introduce a performance issue

Additional info:
Comment 2 Sumit Bose 2021-02-06 12:34:52 UTC 
Hi,

imo it is highly dependent on the server-side implementation if scope=one has a better performance than scope=sub. Most important for the server-side performance are proper indices and if those are available there shouldn't a difference between the scopes assuming that the searched objects are all in the same container. With respect to the documentation we can mention that indices should be used to improve performance, emphasizing the scope might be misleading.

In general SSSD already allows to set the scope with the search base, e.g. for sudo rules see ldap_sudo_search_base in man sssd-ldap for details. So I see no reason to change the default scope.

HTH

bye,
Sumit
Comment 3 Alexey Tikhonov 2021-02-08 13:02:55 UTC 
Updated title based on comment 2.
Comment 11 Pavel Březina 2021-04-26 11:17:53 UTC 
Upstream ticket:
https://github.com/SSSD/sssd/issues/5603
Comment 12 Pavel Březina 2021-04-27 11:23:53 UTC 
Upstream PR:
https://github.com/SSSD/sssd/pull/5610
Comment 13 Pavel Březina 2021-05-07 11:02:49 UTC 
Pushed PR: https://github.com/SSSD/sssd/pull/5610

* `master`
    * b3247eeb562bf92ea7f0938eda6d0203e7cb63c4 - man: document how to tune sudo performance
Comment 14 Steeve Goveas 2021-05-28 14:35:38 UTC 
# man sssd-sudo | awk /'TUNING THE PERFORMANCE'/,/'SEE ALSO'/
TUNING THE PERFORMANCE
       SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values that should satisfy most of our
       users, but the following paragraps contains few tips on how to fine tune the configuration to your requirements.

       1.  Index LDAP attributes. Make sure that following LDAP attributes are indexed: objectClass, cn, entryUSN or modifyTimestamp.

       2.  Set ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup.

       3.  Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may consider increasing the
       ldap_sudo_full_refresh_interval and ldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by setting ldap_sudo_smart_refresh_interval = 0.

       4. If you have large number of clients, you may consider increasing the value of ldap_sudo_random_offset to distribute the load on the server better.

SEE ALSO

[root@auto-hv-01-guest01 ~]# rpm -q sssd
sssd-2.5.0-1.el8.x86_64
Comment 18 Steeve Goveas 2021-06-09 11:39:57 UTC 
[root@vm-idm-023 ~]# man sssd-sudo | awk /'TUNING THE PERFORMANCE'/,/'SEE ALSO'/
TUNING THE PERFORMANCE
       SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values
       that should satisfy most of our users, but the following paragraps contains few tips on how to fine tune the configuration to your requirements.

       1.  Index LDAP attributes. Make sure that following LDAP attributes are indexed: objectClass, cn, entryUSN or modifyTimestamp.

       2.  Set ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup.

       3.  Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may
       consider increasing the ldap_sudo_full_refresh_interval and ldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by setting
       ldap_sudo_smart_refresh_interval = 0.

       4. If you have large number of clients, you may consider increasing the value of ldap_sudo_random_offset to distribute the load on the server better.

SEE ALSO
[root@vm-idm-023 ~]# rpm -q sssd
sssd-2.5.0-1.el8.x86_64
Comment 20 errata-xmlrpc 2021-11-09 19:47:00 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4435
Note You need to log in before you can comment on or make changes to this bug.