You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using sssd in a large LDAP environments, particularly when very large groups are involved (>10k members), memberof can consume quite a lot of CPU time when updating the cache. For example, 'getent group <very_large_group>' may take minutes because of memberof updates. During the memberof operations, sssd is non-functional and other tasks (e.g. logins) will hang until memberof is finished.
I have seen this take up to 7 minutes on a real system, where several large groups (the biggest >36k members) were involved (rfc2307, no nesting). During that time, ssh logins would hang and eventually time out.
One could possibly do some major optimizations if memberof is made aware of whether nesting is involved or not. I think this should be investigated in addition to general optimizations.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/883
When using sssd in a large LDAP environments, particularly when very large groups are involved (>10k members), memberof can consume quite a lot of CPU time when updating the cache. For example, 'getent group <very_large_group>' may take minutes because of memberof updates. During the memberof operations, sssd is non-functional and other tasks (e.g. logins) will hang until memberof is finished.
I have seen this take up to 7 minutes on a real system, where several large groups (the biggest >36k members) were involved (rfc2307, no nesting). During that time, ssh logins would hang and eventually time out.
One could possibly do some major optimizations if memberof is made aware of whether nesting is involved or not. I think this should be investigated in addition to general optimizations.
Comments
Comment from sgallagh at 2011-06-02 15:23:09
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.6.1
Comment from dpal at 2011-07-07 15:27:10
Fields changed
owner: somebody => jzeleny
Comment from sgallagh at 2011-08-26 23:01:54
Fields changed
milestone: SSSD 1.6.1 => SSSD 1.6.2
rhbz: =>
Comment from jzeleny at 2011-09-13 12:59:34
Fields changed
status: new => assigned
Comment from dpal at 2011-10-06 15:40:22
Fields changed
milestone: SSSD 1.6.2 => SSSD 1.7.0
Comment from dpal at 2011-11-03 14:17:14
Fields changed
milestone: SSSD 1.7.0 => SSSD 1.9.0
Comment from dpal at 2012-01-16 16:38:04
"Nice to have" for 1.9.
blockedby: =>
blocking: =>
Comment from dpal at 2012-02-09 15:23:55
So far we identified no advantage in doing this.
feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred
Comment from dpal at 2012-02-10 21:37:03
Fields changed
rhbz: => 0
Comment from jhrozek at 2016-11-17 11:15:08
This was solved by not updating the groups in the first place, so we can close this ticket.
changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
mark: => 0
review: => 1
selected: =>
sensitive: => 0
Comment from jhrozek at 2016-11-25 09:42:42
Fields changed
resolution: => wontfix
status: assigned => closed
Comment from trondham at 2017-02-24 14:49:40
Metadata Update from @trondham:
The text was updated successfully, but these errors were encountered: