#4179 Inefficiency of sdap_nested_group_deref_direct_process()
Closed: cloned-to-github 3 years ago by pbrezina. Opened 3 years ago by atikhonov.

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.

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.

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.

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)

3 years ago

Login to comment on this ticket.

Metadata