Re: slow login with sssd and ldap config

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

 



ok thanks for the precision stephen
do you know when enumeration took place?
Is there a way to have only groups cache for a long time

Le 15/06/2010 14:27, Stephen Gallagher a écrit :
> 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.
>
-- 
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