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
