[SSSD] [PATCH] SYSDB: Index the objectSIDString attribute

Michal Židek mzidek at redhat.com
Tue Aug 18 15:31:43 UTC 2015


On 08/17/2015 10:35 PM, Jakub Hrozek wrote:
> Hi,
>
> the attached patch was confirmed to work, so the code review should be
> easy. But because it adds an index to objectSID, which all AD objects
> have, there are two catches:
>      1) How log the upgrade takes

My main concern was the heartbeat interval. But I just tested it by
adding sleep(50) into your newly added upgrade function and it
work fine with default heartbeat (10 seconds). So I guess monitor
starts pinging the domain backend after it is fully initialized
and not sooner.

>      2) How much the database grows
>
> To test, I created an AD instance with 10.000 users and 10.000 groups
> (adcli is great for this type of testing btw). Fetched all groups and
> users with the old db, then ran the upgrade.
>
> On a VM running on my local laptop (granted, it has an SSD drive), the
> upgrade takes 10 seconds. The default systemd startup timeout
> (DefaultTimeoutStartSec) seems to be 90 seconds, which sounds OK to me.
>
> The size, though, has nearly doubled. This is backup before upgrade:
>      [root at adclient ~]# du -sh /root/cache_win.trust.test.ldb
>      47M     /root/cache_win.trust.test.ldb
> And this is the cache after I upgraded:
>      [root at adclient ~]# du -sh /var/lib/sss/db/cache_win.trust.test.ldb
>      97M     /var/lib/sss/db/cache_win.trust.test.ldb
>
> Unfortunately, I don't see us having another option than doing the
> upgrade. For attributes that are indexed, an index miss means that ldb
> is not going to search sequentially, but just return not found -- so
> adding indexes for newly added entries is not possible.
>
> I would like to document that for huge databases (tens of thousands of
> cached entries), the timeout might need to be raised during the upgrade
> and than for deployments whose cache resides in tmpfs, the cache size
> might grow.
>
> Is everyone OK with this?
>

It should be in realease notes, but I am not sure if that
is enough visible place, so I would suggest putting it to Wiki
as well (https://fedorahosted.org/sssd/wiki/Troubleshooting)
for the case when someone hits the systemd timeout.

ACK to the patch.

Michal



More information about the sssd-devel mailing list