For an LDAP setup using RFC2307bis with many users and nested groups, performing
id username
can take as long as several minutes to complete.
Jakub did an initial investigation into the code and discovered that we aren't using the {{{sysdb_add_fake_user()}}} routine in the RFC2307bis nested group processing, which means that we're resorting to looking up all of the users in those groups. This is very slow.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.6.0 priority: critical => blocker
https://bugzilla.redhat.com/show_bug.cgi?id=681562
patch: => 1 status: new => assigned
Fixed in master:
77bc3d93ddd41edee6046508884d7e95553ed5b7
c18bd9de80daf87e33d60c6c44d83b418cfe37b3
6b95a91c1a49c2eff480820cfd8be51d70a29ffe
7bdaf2a712d73763e7c3d25f6bb544b18f7028eb
resolution: => fixed status: assigned => closed
The problem still exists in 1.6.3
resolution: fixed => rhbz: => status: closed => reopened
milestone: SSSD 1.6.0 => NEEDS_TRIAGE
This request has been coming from several different users running in different environments. I would propose that we gather as much info from the users before we decide on where to optimize.
I think that a systemtap script that generates a callgraph with statistics about how much time do we spend in different functions and perhaps how much time we spend waiting on I/O (both disk and network) would help us here. Then we would at least know whether we should spend time parallelizing the lookups or perhaps profiling the memberof plugin some more..
Replying to [comment:5 mmoeller]:
Marcus, can you measure how slow initgroups are for you?
I would like to ask you to: 1. clear the caches 2. run "id -G $username"
The -G parameter is important - that would make sure only initgroups is performed and "id" would then output the GID numbers of the groups user is a member of. Without the -G parameter, "id" then calls getgrgid() on all the group GIDs which may be very slow (and may not be fixable).
Thank you!
Also when running the test, would you mind telling us how big the group structure is? In other words, how many groups does the user belong to?
blockedby: => blocking: => milestone: NEEDS_TRIAGE => SSSD Deferred
priority: blocker => minor
The issue is already fixed in 1.6. The bug was reopened by mistake.
milestone: SSSD Deferred => SSSD 1.6.0 resolution: => fixed status: reopened => closed
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=742052 (Red Hat Enterprise Linux 6)
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=742052 742052]
Metadata Update from @sgallagh: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.6.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1841
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.