Environment
Novell eDirectory 8.8 for All Platforms
Novell eDirectory 8.7.3 for All Platforms
Situation
LDAP searches for members of dynamic groups or a filter of"objectclass=*" take a very long time.
All indexes are online (member, objectclass and other attributes defined in memberqueryURLs) and cache hit ratios are above 98%.
Problem is reproducible with different releases of Novell eDirectory and across different platforms.
All indexes are online (member, objectclass and other attributes defined in memberqueryURLs) and cache hit ratios are above 98%.
Problem is reproducible with different releases of Novell eDirectory and across different platforms.
Resolution
One possible cause of this behavior could be that the
memberqueryURL for a single/multiple dynamic group is referencing a
different tree. The search is taking long time because of
attempts to resolve a tree name that cannot be looked up in the
network.
An eDirectory trace with the RSLV tag enabled can be used to verify if this is what is causing the performance problem. When doing the query the trace will show that it fails to resolve a bogus tree name. Note that the bogus memberqueryURL might not be normally visible with tools like Novell iManager. An LDAP search for the memberqueryURL attribute will be needed to confirm whether this is the case.
A bogus memberqueryURL might look like the following with an LDAP search:
memberQueryURL: ldap:///OU=DST,O=Landesforsten,C=DE,t=ZEBIT-TEST??sub?(&(!(objectClass=m2UserAccount))(objectClass=inetOrgPerson))
Here the the dynamic group object was migrated from the ZEBIT-TEST tree and references the old tree name. However, this tree does not exist in the network anymore and leads to the resolution delays.
In order to resolve this issue, delete and re-create the concerned dynamic group using Novell iManager or ConsoleOne or LDAP. You can also edit the memberqueryURL attribute to point to the current tree. The second option is only possible with LDAP, though.
An eDirectory trace with the RSLV tag enabled can be used to verify if this is what is causing the performance problem. When doing the query the trace will show that it fails to resolve a bogus tree name. Note that the bogus memberqueryURL might not be normally visible with tools like Novell iManager. An LDAP search for the memberqueryURL attribute will be needed to confirm whether this is the case.
A bogus memberqueryURL might look like the following with an LDAP search:
memberQueryURL: ldap:///OU=DST,O=Landesforsten,C=DE,t=ZEBIT-TEST??sub?(&(!(objectClass=m2UserAccount))(objectClass=inetOrgPerson))
Here the the dynamic group object was migrated from the ZEBIT-TEST tree and references the old tree name. However, this tree does not exist in the network anymore and leads to the resolution delays.
In order to resolve this issue, delete and re-create the concerned dynamic group using Novell iManager or ConsoleOne or LDAP. You can also edit the memberqueryURL attribute to point to the current tree. The second option is only possible with LDAP, though.