Learn more about these different git repos.
Other Git URLs
With a clear cache, running: id $someuser
takes almost 2 seconds. This seems a bit much as sssd is running on a server right next to the ldap server.
Requested information
[jschroeder@container ~]$ for group in $(groups matthiasc | awk '{for (i=3; i <= NF; i++) {print $i}}'); do > members=$(getent group $group | sed -e 's/,/\n/g' | wc -l) > echo "Group $group has $members members" > done Group matthiasc has 1 members Group gnomeweb has 50 members Group gnomecvs has 2089 members Group webusers has 148 members Group ftpadmin has 356 members Group gcvsadm has 23 members
After the gnomecvs group is cached:
[jschroeder@container ~]$ for group in $(groups raywang | awk '{for (i=3; i <= NF; i++) {print $i}}'); do > members=$(getent group $group | sed -e 's/,/\n/g' | wc -l) > echo "Group $group has $members members" > done Group raywang has 1 members Group wheel has 13 members Group snowy has 4 members Group sysadmin has 13 members Group mailusers has 340 members Group foundation has 318 members Group gnomecvs has 2089 members Group accounts has 18 members [jschroeder@container ~]$
Perhaps this is expected behavior, but it seems a bit slow.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.6.0
owner: somebody => jzeleny
What schema are you using?
I don't actually know. My groups have memberUid attributes and a user would look like this:
uid=jschroeder,ou=People,o=int uid: jschroeder uidNumber: 7084 homeDirectory: /home/jschroeder loginShell: /bin/bash gidNumber: 100 sn: Schroeder mail: my@email.com displayName: Jeff Schroeder cn: Jeff Schroeder gecos: Jeff Schroeder st: CA departmentNumber: IT l: Los Angeles title: Sr Systems Administrator givenName: Jeff authorizedKey: ssh-dss AAAAB3NzaC1kc3MAAACBAK/fPV9YvwOqOxNui+dZCoFMhH313D++2Mm1cR/flGCh0TEe20Vdv8hnFU06khY9ndo9MtPe0LyDw65lLAv1yu4Gjr7vsl6Yt4OC6u1oq3TG/YdFrMoTpy5yp4bQpfP9tueMj18kPq4RpHVJ2kqeZytwV4p3nnXzwRWs8BPWEuhbAAAAFQD95EKNg5d9sXKZkMPREJ+CTs8UPQAAAIBixMwLitdWz4viUFHkZ8DZIxSQwO5C5jfTSYizDBCCTmmxJbb/RyKc3Veaar88H7+gBaECvuOI90kZWNzCrjCSpQgLg5AiXvphPbzZdKHmpjzn5pF4908YZESGY0iTpCOTfo3PisUBb9zNh7j/HDI7sS33g7ZwJWnTPOLJCYz3FwAAAIEAgcfMYrt61DUSf175em4WC8MTo002EHewPmfCcFeT8/n9A3hGhmFFY8L4tFXKMeeBASN+LhJJXKcXOiMG+kJkk6ysASrq7psFoJKEGPccaqgZywHDt3icgbJKQjJicujDPr6SdNTdg2m0t+os8YQMlOYRPlQC2gtkbZWU+iV/GQQ= my@email.com objectClass: inetOrgPerson objectClass: person objectClass: posixAccount objectClass: pubkeyAuthenticationUser objectClass: shadowAccount objectClass: top userPassword: ... postalCode: 90025 street: my address
pubkeyAuthenticationUser is our own custom schema. So, what schema type is that? I looked at the include lines on the slapd.conf of on of the ldap servers, but don't honestly know.
If I recall correctly, sgallagh was able to reproduce this bug and asked me to file this ticket.
It should be rfc2307, which is already tuned for good performance (for rfc2307 some optimizations are currently developed).
I did some profiling and I'm afraid there is not much we can to without considerable change of our caching approach. The highest slowdown is caused by ldb. More precisely by large number of write operations (add/modify) performed on the ldb cache. Considering this I think we should either close this ticket or defer it. If anyone is interested, I can send the profiling output of callgrind.
milestone: SSSD 1.6.0 => NEEDS_TRIAGE
I'm sending the profiling output as Stephen asked me callgrind.out.10015
milestone: NEEDS_TRIAGE => SSSD 1.6.0 patch: => 0
Ok, I did some testing and so far I found out this: 'id' operation has two parts. First the initgroups operation is called which returns a list of GIDs. Then for each group a request is made to the server which loads more information about the group.
I tested the operation on a member of couple large groups. The whole operation took 2.494 seconds. Approximately 1.117 seconds was taken by initgroups operation (retrieving the data from LDAP takes 0.79 seconds). The rest of the time was taken by retrieving information about other groups. In this phase, considerable amount of time is consumed by storing all the member in the sysdb (apx. 0.84 seconds).
status: new => assigned
milestone: SSSD 1.6.0 => SSSD 1.6.1 priority: minor => major
milestone: SSSD 1.6.1 => SSSD 1.6.2 rhbz: =>
Marking as a duplicate of 883 and 635 (both of which together should solve this issue).
resolution: => duplicate status: assigned => closed
rhbz: => 0
Metadata Update from @sejeff: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.6.2
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/1830
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.
Login to comment on this ticket.