We're struggeling with the performance of IPA, and have tried switching to the ldap backend for sssd to be able to see what's happening. The attached trace is from a RHEL6.4 client running "id janfrode" with the following sssd backend:
----------------------------------------------------------------------- [domain/IPALDAP] id_provider = ldap auth_provider = ldap ldap_schema = rfc2307bis ldap_uri = ldap://ipa2.example.net, ldap://ipa1.example.net ldap_search_base = dc=example,dc=net ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=net ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=net ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=net ldap_tls_cacert = /etc/ipa/ca.crt ldap_tls_reqcert = never cache_credentials = True enumerate = false debug_level = 1 krb5_server = ipa1.example.net ----------------------------------------------------------------------- Please ignore the timings in the trace, as the ldap-server had too high debug level when it was collected. What we find very strange in the trace is: - how many ldap searches are done (144!) - that nesting is handled by the client, instead of using "memberOf". - that all group members are searched individually, and multiple times if they're members of multiple groups Ldap-searches are probably (without this high debug level) taking 0.02-0.03s, so 144 of these is causing us 3-4s to resolve all my groups. I can get the time "id janfrode" takes down to less than 1s if I use ldap_schema=rfc2307, turn of nesting and use the cn=compat tree for group lookups... but ideally I'd want to use the ipa-backend so that we can use the IPA HBAC stuff.. -jf
trace.bz2
Description: BZip2 compressed data
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
