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
