[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: question about limits



Pierangelo Masarati wrote:

Hi,

I have a question about limits:

when I do a query like :

ldapsearch -x -b"o=mail,dc=example,dc=com" -w password
-D"userlogin=user,o=admins,dc=example,dc=com" -LLL
"(&(mail=*@example.com)(objectClass=mailUser))"

where o=mail,dc=example,dc=com (objectClass=mailUser) contains about
50000 entries (indexed)



What indices?



# Indexing options
index           objectClass,customerRoot        eq,pres
index           mailDomain,mail,userlogin       eq,pres,sub
index           o,cn,sn                         eq,pres,sub
index           maildir,primarySmtp             eq,pres
index           mailmessagestore                eq,pres
index           homeDirectory,maildrop          eq,pres
index           FTPHomedirectory                eq,pres
index           dc,associatedDomain             eq,pres

the query takes about 35 seconds to complete.

but when I do it like this:

ldapsearch -x -b"o=mail,dc=example,dc=com" -w password
-D"cn=admin,dc=example,dc=com" -LLL
"(&(mail=*@example.com)(objectClass=mailUser))"

where : cn=admin,dc=example,dc=com is the root database admin the query
takes about 0.4 seconds



ACL problem? How many (regex) ACLs are you using?



access to dn=".*,o=admins,dc=example,dc=com"
       attr=userPassword
       by anonymous auth
       by self write
       by * none

access to dn="o=admins,dc=example,dc=com"
       by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" read
       by * none

access to dn=".*,customerRoot=([^,]+),o=customers,dc=example,dc=com"
attr=userPassword
by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" write
by dn="userlogin=[^,]+,customerRoot=$1,o=customers,dc=example,dc=com" write
by anonymous auth
by self write
by * none


access to dn=".*,customerRoot=([^,]+),o=customers,dc=example,dc=com"
by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" write
by dn="userlogin=[^,]+,customerRoot=$1,o=customers,dc=example,dc=com" write
by * none


access to dn="o=customers,dc=example,dc=com"
       by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" write
       by * none

access to dn=".*,customerRoot=([^,]+),o=[^,]+,dc=example,dc=com"
attr=userPassword
by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" write
by dn="userlogin=[^,]+,customerRoot=$1,o=customers,dc=example,dc=com" write
by anonymous auth
by self write
by * none


access to dn=".*,customerRoot=([^,]+),o=[^,]+,dc=example,dc=com"
by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" write
by dn="userlogin=[^,]+,customerRoot=$1,o=customers,dc=example,dc=com" write
by * read


access to *
       by dn="userlogin=[^,]+,o=admins,dc=example,dc=com" write
       by * read


and  when I do this:

ldapsearch -x -b"o=mail,dc=example,dc=com" -w password
-D"userlogin=user,o=admins,dc=example,dc=com" -LLL
"(&(mail=*@example.com*)(objectClass=mailUser))"

the query takes about 0.05 seconds.



Again, what indices did you use?



I have tried:
- sizelimt size.unckecked=-1
- sizelimit size.hard=-1



It is not clear what limits have to do with your problem. If limits are hit, either the search doesn't occur or only a fraction of the expected results is returned. I don't think this will solve your problem; only, they should help in alleviating your server's load for those undesired operations. I note that sizelimit.unchecked=-1 is the default, so setting it is useless unless previouly overriden by any other directive. Also, size.hard=-1 is only useful if you specify a sizelimit request with your search (e.g. you use the -z flag with ldapsearch).



but query 1 still takes about 30 seconds (with a cpu load of 99%)

and query 3 is totally strange....



what do you mean with "strange"? Is it just faster than search 1?


why should a search with more wildcards be quicker...

and even more strange the 'slowness' is not on every domain searched, there are domains where the results are returned quickly with query 1.

I have tried this with 1 ACL and the problem is still there....

--
JJ van Gorkum                             Knowledge Zone
If UNIX isn't the solution, you've got the wrong problem