On Thu, Sep 03, 2015 at 06:24:35AM +0200, Lukas Slebodnik wrote:
> On (19/08/15 18:15), Jakub Hrozek wrote:
> >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
I think so, I will push it unless there is some oposition due to the
upgrade taking potentially too long.