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 < [email protected]> 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 >
