Thank you both for the advice. I appreciate it.
It seems like indexing aliasedObjectName helped. but I also put a problem system on its own replica. load from slapd seemed to drop from 1500% down to a normal level, <50%.
Instead of having separate copies of each user in separate branches. We just have a master branch and alias the users into the branches for systems they are allowed access into. It seemed like an efficient way to do things. We'd only have to update a single object if the user ever had any change. Otherwise we'd have to maintain a copy of each user object in each instance they belonged to.
Maybe I'll have to rethink our architecture. Any recommendations?
On Fri, Jul 14, 2017 at 11:41 AM, Hallvard Breien Furuseth < h.b.furuseth@usit.uio.no> wrote:
On 13. juli 2017 16:35, Josh Catana wrote:
We heavily rely on aliases to different OUs to manage access to different environments, prod/dev/qa/etc.
Don't. Having lots of aliases cancels out the effect of your indexes:
Looking at what it's doing it spending a lot of time with bld_idl_union in
the BDB backend. (...) Is this because it has to join aliases to actual CNs?
Yes. Indexing does not look "through" an alias, so a search which follows aliases must follow every alias in the search scope in order to check each aliased entry with the filter.
Can I index the alias attribute and if I do would it help performance?
Nope. The best you can do is to index objectClass, which you should. That tells slapd which entries are alias entries, referral entries etc.
-- Hallvard