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