I've been noticing slapd slow responsive time as my environment has been growing.
Running on sles11sp3 openldap2-2.4.26-0.62.2 BDB backend.
We heavily rely on aliases to different OUs to manage access to different environments, prod/dev/qa/etc.
I know I should probably update the backend, but this isn't what the question is about.
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?
Can I index the alias attribute and if I do would it help performance?
Thanks.
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.
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
On 14/07/17 20:57, Josh Catana wrote:
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%.
Nice replica:-) I don't see how indexing aliasedObjectName could help.
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?
If you have a deep structure with something like uid=username,ou=foo,ou=bar,ou=baz,dc=example,dc=com switch to a flat uid=username,cn=people,dc=example,dc=com where each person has a membership attribute or something similar which says where he belongs. See e.g. attribute eduPersonOrgUnitDN in the eduPerson schema: http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602....
If that's not feasible, go with with data duplication: Keep a single "master" copy of each user somewhere - in an LDAP server or somewhere else - and generate his other LDAP entries from that.
openldap-technical@openldap.org
-
Hallvard Breien Furuseth -
Josh Catana