Finally got around to purging our old users from our Sun LDAP server last week. A quick perl script to find all of the users that msuserpurge had marked as removed and all looked good until I attempted to run it.
First 5 deletes happened almost instantly and then it all ground to a halt. It ended up deleting 5 accounts every 9 minutes which was a little worrying given that I had 12000 to delete. Also, the cpu usage of slapd rocketed and it started thrashing the disks like mad. More investigation required…
Prime suspect was the referential integrity plugin. This is a neat plugin to directory server that monitors for deletes and renames and then updates any other entries to ensure referential integrity is maintained throughout the ldap tree. Dead handy but potentially resource hungry.
A bit of digging turned up a blog with some really handy info on (why isn’t this stuff in the manual??) and some tuning info that helped reduce the cpu hit but it was still taking forever to delete users. I checked and double checked the indexes – all looked fine.
Suddenly, a tiny comment on this page rang alarm bells
“All attributes in all databases that are used by the referential integrity plug-in must be indexed. The indexes need to be created in the configuration of all the databases. When the retro change log is enabled, the cn=changelog suffix must be indexed.”
We have a cn=changelog suffix – and it had one of the indexes missing. Sorting that out meant that instead of 5 deletes every 9 minutes I suddenly managed to delete 12000 accounts in 6 minutes. Quite a speed up 🙂
Of course, I now need to work out why we have retro changelog running (and how to prune it – it has almost a million entries at he moment!). We are running multimaster replication which I’d assumed was the reason but the docs suggest that this is just for old v4 compatability. Given we don’t have and old directory servers maybe we can just turn it off.
Anyway, hope this helps someone and avoids someone scratching their head for a couple of hours like I did 🙂