Ticket #799 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

RFC2307bis 'id' lookups are prohibitively slow

Reported by: sgallagh Owned by: jhrozek
Priority: minor Milestone: SSSD 1.6.0
Component: LDAP Provider Version: 1.5.1
Keywords: Cc:
Blocked By: Blocking:
Sensitive: Tests Updated: no
Coverity Bug: Patch Submitted: yes
Red Hat Bugzilla: 742052 Design link:
Feature Milestone:
Design review: Fedora test page:
Chosen: Candidate to push out:
Release Notes:
Temp mark:


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.

Change History

comment:1 Changed 6 years ago by sbose

  • Priority changed from critical to blocker
  • Milestone changed from NEEDS_TRIAGE to SSSD 1.6.0

comment:3 Changed 6 years ago by jhrozek

  • Status changed from new to assigned
  • Patch Submitted set

comment:5 follow-up: ↓ 8 Changed 5 years ago by mmoeller

  • Status changed from closed to reopened
  • Resolution fixed deleted

The problem still exists in 1.6.3

comment:6 Changed 5 years ago by sgallagh

  • Milestone changed from SSSD 1.6.0 to NEEDS_TRIAGE

comment:7 Changed 5 years ago by jhrozek

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..

comment:8 in reply to: ↑ 5 Changed 5 years ago by jhrozek

Replying to mmoeller:

The problem still exists in 1.6.3

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!

comment:9 Changed 5 years ago by jhrozek

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?

comment:10 Changed 5 years ago by dpal

  • Milestone changed from NEEDS_TRIAGE to SSSD Deferred

comment:11 Changed 5 years ago by dpal

  • Priority changed from blocker to minor

comment:12 Changed 5 years ago by dpal

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Milestone changed from SSSD Deferred to SSSD 1.6.0

The issue is already fixed in 1.6. The bug was reopened by mistake.

comment:13 Changed 5 years ago by sgallagh

  • Red Hat Bugzilla set to [https://bugzilla.redhat.com/show_bug.cgi?id=742052 742052]

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=742052 (Red Hat Enterprise Linux 6)

Note: See TracTickets for help on using tickets.