On 08/04/2015 11:57 AM, ghiureai wrote:
<
https://www.flowdock.com/app/canfar/access-control/threads/QyygOboGumgx3q...
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|
Regards,
Mark
<
https://www.flowdock.com/app/canfar/access-control/threads/uabfakR5BK-gHR...
# search result
search: 2
result: 0 Success
# numResponses: 2608
# numEntries: 2607
real 0m19.284s
user 0m0.040s
sys 0m0.052s
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users