[389-users] 389-DS poor performance retrieving groups
ghiureai
isabella.ghiurea at nrc-cnrc.gc.ca
Wed Aug 5 18:31:45 UTC 2015
Mark, would be accepted to accommodate only substring indexes
followed by wild char than ?
aka :cn=abc*,
cn=efg* .... may need couple of this indexes.
Thank you
[389-users] 389-DS poor performance retrieving groups
On 08/05/2015 08:24 AM, Mark Reynolds wrote:
>/
/>/
/>/ On 08/04/2015 11:57 AM, ghiureai wrote:
/>>/ <https://www.flowdock.com/app/canfar/access-control/threads/QyygOboGumgx3qw3tIO_828AMgQ>
/>>/
/>>/ We are seeing poor performance from LDAP retrieving 2500-4500 entries
/>>/ compare with one of our regular RDBMS , here is bellow the result for
/>>/ a ldapsearch.
/>>/ We are questioning if for general cn=(.*..) search string , LDAP has
/>>/ to run a round trip for each subset result entry ?
/>>/
/>>/ What cfg needs tuned to see some performance improvements beside
/>>/ cache mem size ?
/>>/
/>>/ ldapsearch -x -s one -H -b 'ou=Groups,ou=ds,dc=cxxx,dc=net' -W -D
/>>/ 'uid=xx,ou=Users,ou=ds,dc=cxxxr,dc=net' 'cn=*MT*' 'cn, nsaccountlock'
/>/ Okay so this is probably unindexed, and the requested access log
/>/ snipet will confirm this. If you see notes=U or notes=A then we can
/>/ tune the id scan limit for that search:
/>/
/>/
/>/ Assuming this is the only search that is giving you issues:
/>/
/>/ Example:
/>/
/>/
/>/ # ldapmodify <fill in the required parameters>
/>/ |dn: cn=cn,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config
/>/ changetype: modify
/>/ add:|||nsIndexIDListScanLimit|
/>/ nsIndexIDListScanLimit: limit=-1 type=sub values=*mt,mt*
/>/
/>/
/>/
/>/ If there are other substring searches around the "cn" attribute you are having issues with, you can modify this to be:
/>/
/>/ |# ldapmodify <fill in the required parameters>
/>/
/>/ |dn: cn=cn,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config
/>/ changetype: modify
/>/ add:|||nsIndexIDListScanLimit|
/>/ nsIndexIDListScanLimit: limit=-1 type=sub|
/I'm on a roll today :-( sorry so this is not going to solve the issue.
There is no way to index or improve this type of search filter's
performance (cn=*mt*). If this is a reoccurring search filter, and your
client can be adjusted to use vlv indexes, then that might be option.
See the admin guide for more info on VLV searches/indexes.
Regards,
Mark
>/
/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20150805/9df06b9d/attachment.html>
More information about the 389-users
mailing list