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.
Michal