Re: slow login with sssd and ldap config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/15/2010 08:15 AM, Eric Doutreleau wrote:
> Hi
>
> I have some news about that problems
> i though it was solved because i configured the groups to follow an
> empty part of my ldap server.
> I have configured the groups to read in the good part of my ldap server
> and the slow performance is back again.
>
> There s someting strang by the way
> on my machine i type
> id doutrele
> on the sssd_default.log i can read the following line
> (Tue Jun 15 14:00:38 2010) [sssd[be[default]]] [be_get_account_info]
> (4): Got request for [4097][1][name=doutrele]
> then a ton of lines where the system try to find of which group the user
> doutrele belong.
> then i read
> (Tue Jun 15 14:00:39 2010) [sssd[be[default]]] [ldb] (9): Entry not
> found (name=zou,cn=users,cn=default,cn=sysdb)
> (Tue Jun 15 14:00:40 2010) [sssd[be[default]]] [sdap_save_groups_loop]
> (9): Group 5 processed!
> (Tue Jun 15 14:00:40 2010) [sssd[be[default]]] [sdap_save_group_send]
> (7): Adding original DN
> [cn=CampusTMSP,ou=Group,ou=System,dc=int-evry,dc=fr] to attributes of
> [CampusTMSP].
> (Tue Jun 15 14:00:40 2010) [sssd[be[default]]] [sdap_save_group_send]
> (7): Adding member users to group [CampusTMSP]
>
> (Tue Jun 15 14:00:40 2010) [sssd[be[default]]] [sdap_save_group_send]
> (7): Adding member users to group [CampusTMSP]
>
> he saved a lot of groups in the local cache and proceed the last group
> CampusTMSP
> and i read that
> (Tue Jun 15 14:00:42 2010) [sssd[be[default]]] [ldb] (9): Entry not
> found (name=zriouil,cn=users,cn=default,cn=sysdb)
> (Tue Jun 15 14:00:42 2010) [sssd[be[default]]] [ldb] (9): Entry not
> found (name=zryouil,cn=users,cn=default,cn=sysdb)
> (Tue Jun 15 14:02:32 2010) [sssd[be[default]]] [sdap_save_groups_loop]
> (9): Group 6 processed!
>
> then it takes 1m50s to save the last group.
> is there a way to speed up that process?

This is what I was trying to mention in my last email. We have a serious 
bottleneck in the 1.2.0 codebase when dealing with users who are members 
of groups with large numbers of users.

This is fixed in the current upstream version (that will eventually 
become 1.3.0) as a side-effect of a complete rewrite of our cache logic.

In the current 1.2.0 codebase, however, it is probably in your best 
interest to operate with 'enumerate = True' in your sssd.conf, as this 
will preload all of the group entries, so they are retrieved from cache 
instead of going to the server and updating the cache on request.

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux