#1191 Cache the last getgrnam|gid call results if glibc provides a small buffer
Closed: Fixed None Opened 12 years ago by jhrozek.

Currently if glibc's getgrnam function is called and provides a buffer that is not big enough to contain all the members, the nss_sss module returns NSS_STATTUS_TRYAGAIN. Then glibc retries with a bigger buffer, but the sss module performs another round-trip to the nss responder. For a group with 8000 users, I've seen 9 round trips until the sss module was able to return data.

Simo proposed that we should cache results if (and only if) the buffer provided by glibc is too small. The details were discussed on IRC:

15:55 < jhrozek> What I'm seeing is that sssd_nss always returns *all* members, returns all to sss_nss, which can't stuff the results into the given buffer and returns TRYAGAIN.
15:56 < simo> jhrozek, ok then we need an optimization where we cache the last call
15:56 < simo> so that repeated calls due to small buffers do not cause roundtrips
15:56 < sgallagh> simo: Except, what happens if glibc does not in fact TRYAGAIN?
15:56 < simo> jhrozek, it should be a very simple patch
15:56 < simo> jhrozek, we already do that for enumerations
15:57 < simo> sgallagh, the next get** call will free the cache
15:57 < sgallagh> Ok, true.
15:57 < simo> or we will waste 8k of memory ... big deal
15:57 < sgallagh> Sounds like a plan, then
15:57 < simo> the cache needs to be a global
15:57 < simo> and needs locking for multithreaded applications
15:57 < simo> uhmm maybe we can avoid locking and have just thread-local storage for this one ...
15:58 < simo> a mutex is simpler for now (we already have a mutex around the fd communication
15:58 < jhrozek> simo: sounds good to me. Would you like to file a ticket or shall I?
15:59 < simo> and will keep memory low as only one storage will be involved, with tls we could have hundreds of abandoned buffers
15:59 < simo> jhrozek, feel free
15:59 < simo> ah one last thing
15:59 < simo> cache *only* if the buffer is too small
15:59 < simo> no need for caching in libnss_sss otherwise we would just thrash constantly
15:59 < jhrozek> OK

Fields changed

owner: somebody => jhrozek
status: new => assigned

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.8.0 (LTM)

Fixed by:
- fd98474 (master)
- e77506c (sssd-1-8)

patch: 0 => 1
resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.8.0 (LTM)

7 years ago

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/2233

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.

Login to comment on this ticket.

Metadata