On Tue, Aug 18, 2015 at 05:31:43PM +0200, Michal Židek wrote:
> 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@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@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.
* master: e61b0e41cb44004d2b260ad9d05802995f7bcb2e
Shall we push this performance
enhancement to stable branch(1.12) as well?
LS