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 <userid>" 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?
Thanks,
Franky
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 <userid>" 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-leave@lists.fedorahosted.org
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 <userid>" 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
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 <userid>" 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-leave@lists.fedorahosted.org
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 <userid>" 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
Was that bug per chance https://pagure.io/SSSD/sssd/issue/3425 ?
On 8 Dec 2017, at 11:57, Franky Van Liedekerke liedekef@telenet.be wrote:
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).
sssd-users@lists.fedorahosted.org