[SSSD-users] Re: fast cache corruption
On (08/12/17 12:07), Sumit Bose wrote: >On Fri, Dec 08, 2017 at 11:57:23AM +0100, Franky Van Liedekerke wrote: >> Op Vrijdag, 08-12-2017 om 11:34 schreef Sumit Bose: >> > On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote: >> > > Before opening a bug report, I wanted to discuss a new issue here. >> > > >> > > I have ldap users that are in 1500 groups (yeah, I know ... not my >> > > choice either), ldap is using rfc2307 scheme (openldap, redhat EL7). >> > > Now, when connecting sssd to this ldap server, I've already set >> > > enumeration=false, and also ignore_group_members=true (performance ...). >> > > However, with ignore_group_members=true, I'm getting this in the >> > > sssd_nss.log when doing a 'groups " command: >> > > >> > > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr >> > > value is 16 >> > > >> > > (once when the cache is empty, and after that once or twice per >> > > groups-request). >> > > I also see this in /var/log/messages (related of course): >> > > >> > > sssd[nss]: Stored copy of corrupted mmap cache in file >> > > '/var/lib/sss/mc/group_corrupted#012' >> > > >> > > As a result, this prevents the use of the sssd fast cache, so group >> > > requests at best take 5.5 seconds. >> > > Now this problem happens 95% of the cases (which leads me to believe it >> > > is a timing bug), but when I set ignore_group_members=false, this is not >> > > happening (and when groups are ok in the fast cache: 0,03 secs response >> > > time). >> > > >> > > Ideas? Hints? Or should I just go and open a bug report? Is there a real >> > > performance drawback to setting ignore_group_members=false? >> > >> > There is already a BZ >> > https://bugzilla.redhat.com/show_bug.cgi?id=1490120. >> > >> > I think in your setup (plain LDAP with rfc2307) the performance loss >> > when using ignore_group_members=false (the default) should be >> > acceptable. >> > >> > bye, >> > Sumit >> >> Unfortunately I can't view the content of that BZ (no access, I'm searching >> for an account at my current company that does), so any insight/summary on >> that one would be appreciated. > >Here is the related upstream ticket >https://pagure.io/SSSD/sssd/issue/3571. > And it is fixed in copr and fedora 25+ https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-15/ LS ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: fast cache corruption
On Fri, Dec 08, 2017 at 11:57:23AM +0100, Franky Van Liedekerke wrote: > Op Vrijdag, 08-12-2017 om 11:34 schreef Sumit Bose: > > On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote: > > > Before opening a bug report, I wanted to discuss a new issue here. > > > > > > I have ldap users that are in 1500 groups (yeah, I know ... not my choice > > > either), ldap is using rfc2307 scheme (openldap, redhat EL7). > > > Now, when connecting sssd to this ldap server, I've already set > > > enumeration=false, and also ignore_group_members=true (performance ...). > > > However, with ignore_group_members=true, I'm getting this in the > > > sssd_nss.log when doing a 'groups " command: > > > > > > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr > > > value is 16 > > > > > > (once when the cache is empty, and after that once or twice per > > > groups-request). > > > I also see this in /var/log/messages (related of course): > > > > > > sssd[nss]: Stored copy of corrupted mmap cache in file > > > '/var/lib/sss/mc/group_corrupted#012' > > > > > > As a result, this prevents the use of the sssd fast cache, so group > > > requests at best take 5.5 seconds. > > > Now this problem happens 95% of the cases (which leads me to believe it > > > is a timing bug), but when I set ignore_group_members=false, this is not > > > happening (and when groups are ok in the fast cache: 0,03 secs response > > > time). > > > > > > Ideas? Hints? Or should I just go and open a bug report? Is there a real > > > performance drawback to setting ignore_group_members=false? > > > > There is already a BZ > > https://bugzilla.redhat.com/show_bug.cgi?id=1490120. > > > > I think in your setup (plain LDAP with rfc2307) the performance loss > > when using ignore_group_members=false (the default) should be > > acceptable. > > > > bye, > > Sumit > > Unfortunately I can't view the content of that BZ (no access, I'm searching > for an account at my current company that does), so any insight/summary on > that one would be appreciated. Here is the related upstream ticket https://pagure.io/SSSD/sssd/issue/3571. > Fun fact just for info: we had to switch to rfc2307 (from 2307bis) because of > another bug in sssd that ignores the setting to not do nested group searches, > which resulted in a huge amount of extra ldap searches per user (1 per group). Did you open a ticket about this? bye, Sumit > > Franky > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: fast cache corruption
Op Vrijdag, 08-12-2017 om 11:34 schreef Sumit Bose: > On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote: > > Before opening a bug report, I wanted to discuss a new issue here. > > > > I have ldap users that are in 1500 groups (yeah, I know ... not my choice > > either), ldap is using rfc2307 scheme (openldap, redhat EL7). > > Now, when connecting sssd to this ldap server, I've already set > > enumeration=false, and also ignore_group_members=true (performance ...). > > However, with ignore_group_members=true, I'm getting this in the > > sssd_nss.log when doing a 'groups " command: > > > > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr > > value is 16 > > > > (once when the cache is empty, and after that once or twice per > > groups-request). > > I also see this in /var/log/messages (related of course): > > > > sssd[nss]: Stored copy of corrupted mmap cache in file > > '/var/lib/sss/mc/group_corrupted#012' > > > > As a result, this prevents the use of the sssd fast cache, so group > > requests at best take 5.5 seconds. > > Now this problem happens 95% of the cases (which leads me to believe it is > > a timing bug), but when I set ignore_group_members=false, this is not > > happening (and when groups are ok in the fast cache: 0,03 secs response > > time). > > > > Ideas? Hints? Or should I just go and open a bug report? Is there a real > > performance drawback to setting ignore_group_members=false? > > There is already a BZ > https://bugzilla.redhat.com/show_bug.cgi?id=1490120. > > I think in your setup (plain LDAP with rfc2307) the performance loss > when using ignore_group_members=false (the default) should be > acceptable. > > bye, > Sumit Unfortunately I can't view the content of that BZ (no access, I'm searching for an account at my current company that does), so any insight/summary on that one would be appreciated. Fun fact just for info: we had to switch to rfc2307 (from 2307bis) because of another bug in sssd that ignores the setting to not do nested group searches, which resulted in a huge amount of extra ldap searches per user (1 per group). Franky ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: fast cache corruption
On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote: > Before opening a bug report, I wanted to discuss a new issue here. > > I have ldap users that are in 1500 groups (yeah, I know ... not my choice > either), ldap is using rfc2307 scheme (openldap, redhat EL7). > Now, when connecting sssd to this ldap server, I've already set > enumeration=false, and also ignore_group_members=true (performance ...). > However, with ignore_group_members=true, I'm getting this in the sssd_nss.log > when doing a 'groups " command: > > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr > value is 16 > > (once when the cache is empty, and after that once or twice per > groups-request). > I also see this in /var/log/messages (related of course): > > sssd[nss]: Stored copy of corrupted mmap cache in file > '/var/lib/sss/mc/group_corrupted#012' > > As a result, this prevents the use of the sssd fast cache, so group requests > at best take 5.5 seconds. > Now this problem happens 95% of the cases (which leads me to believe it is a > timing bug), but when I set ignore_group_members=false, this is not happening > (and when groups are ok in the fast cache: 0,03 secs response time). > > Ideas? Hints? Or should I just go and open a bug report? Is there a real > performance drawback to setting ignore_group_members=false? There is already a BZ https://bugzilla.redhat.com/show_bug.cgi?id=1490120. I think in your setup (plain LDAP with rfc2307) the performance loss when using ignore_group_members=false (the default) should be acceptable. bye, Sumit > > Thanks, > > Franky > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
