On 08/04/2015 11:57 AM, ghiureai wrote:
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

# 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users