Learn more about these different git repos.
Other Git URLs
09:58:11 2020) [sssd[be[*****]] [sdap_nested_group_deref_direct_process] (0x2000): Received 59874 dereference results, about to process them 09:58:11 2020) [sssd[be[*****]] [sdap_nested_group_hash_insert] (0x4000): Inserting [CN=***,...] into hash table [users] ... 09:58:45 2020) [sssd[be[*****]] [sdap_nested_group_hash_insert] (0x4000): Inserting [CN=***,...] into hash table [users] 09:58:45 2020) [sssd[be[*****]] [orderly_shutdown] (0x0010): SIGTERM: killing children
-- execution of sdap_nested_group_deref_direct_process() for 59874 entries took 34 seconds.
sdap_nested_group_deref_direct_process()
This feels unjustifiably long, taking into account this function only rearrange data in RAM.
This is often (partial) reason for internal watchdog to terminate sssd_be.
One of the reasons can be that both group_ctx->users and group_ctx->groups hash tables are initially created with count == 32. This value is used to determine directory_size and segment_size. From a quick glance it looks like those values are never re-calculated. Perhaps, directory and segment sizes based on count==32 are very inefficient to store 50+k entries.
group_ctx->users
group_ctx->groups
count == 32
directory_size
segment_size
count==32
But I am not sure if this is the only / major reason.
There are other potentially expensive operations. For example, this reallocation can be another source.
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/5134
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.