16 Jun
2009
16 Jun
'09
12:50 a.m.
On 15/06/2009 20:38, Tihomir Culjaga wrote:
can anyone help ?
On Mon, Jun 15, 2009 at 3:58 PM, Tihomir Culjaga <tculjaga@gmail.com mailto:tculjaga@gmail.com> wrote:
oh, yes... forgot to say ... i have approx 2 milion entries within the LDAP. T. On Mon, Jun 15, 2009 at 3:53 PM, Tihomir Culjaga <tculjaga@gmail.com <mailto:tculjaga@gmail.com>> wrote: Same issue:... one request takes 93 ms the other 7 ms...
Hi,
What version of OpenLDAP are you using? I recall there being some issues recently with freeing cache on large databases. You may be running into this since you have 2 million entries and cachesize set to 600000 - thus not all entries fit in the cache. Whichever, I recommend using the latest, 2.4.16.
If performance is very important to you, you might consider optimising your cache parameters some more. Ideally, you could store all the BDB indexes (all *.bdb files in the BDB directory) in memory, and all entries.
If you have enough memory, and all your entries are likely to be requested, set cachesize higher than 2 million. See this FAQ entry for some more details: http://www.openldap.org/faq/data/cache/1075.html.
Regards, Jonathan
~$ time ldapsearch -h localhost -x -b ou=redirecting,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w **** uniqueID=38512303736 1.1 # extended LDIF # # LDAPv3 # base <ou=redirecting,ou=sipDirektor,dc=ot,dc=hr> with scope subtree # filter: uniqueID=38512303736 # requesting: 1.1 # # 38512303736, redirecting, sipDirektor, ot.hr <http://ot.hr> dn: uniqueID=38512303736,ou=redirecting,ou=sipDirektor,dc=ot,dc=hr # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 real 0m0.093s user 0m0.004s sys 0m0.004s ~$ time ldapsearch -h localhost -x -b ou=redirecting,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w **** uniqueID=38515000400 1.1 # extended LDIF # # LDAPv3 # base <ou=redirecting,ou=sipDirektor,dc=ot,dc=hr> with scope subtree # filter: uniqueID=38515000400 # requesting: 1.1 # # 38515000400, redirecting, sipDirektor, ot.hr <http://ot.hr> dn: uniqueID=38515000400,ou=redirecting,ou=sipDirektor,dc=ot,dc=hr # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 real 0m0.007s user 0m0.000s sys 0m0.000s this is my DB_CONFIG # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27 ghenry Exp $ # Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. # # See the Oracle Berkeley DB documentation # <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html> # for detail description of DB_CONFIG syntax and semantics. # # Hints can also be found in the OpenLDAP Software FAQ # <http://www.openldap.org/faq/index.cgi?file=2> # in particular: # <http://www.openldap.org/faq/index.cgi?file=1075> # Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment. # one 0.25 GB cache # set_cachesize 0 268435456 1 # one 768 MB cache #set_cachesize 0 805306368 1 # one 1GB cache set_cachesize 0 1073741824 1 # Data Directory #set_data_dir db # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 #set_lg_dir logs # Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option). and this is my slapd.conf ~$ cat /etc/ldap/slapd.conf include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/sipdirector.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel 0 access to dn.base="" by * read access to * by dn="cn=admin,dc=ot,dc=hr" write by * read threads 8 ####################################################################### # BDB database definitions ####################################################################### backend bdb database bdb cachesize 600000 idlcachesize 1800000 cachefree 1000 suffix "dc=ot,dc=hr" rootdn "cn=admin,dc=ot,dc=hr" // rootpw **** :) directory /usr/local/var/openldap-data index objectClass eq index uniqueID eq On Mon, Jun 15, 2009 at 3:01 PM, jakjr <joao.alfredo@gmail.com <mailto:joao.alfredo@gmail.com>> wrote: Are the attrs list returned in both entries euqal ? Try to use the 1.1 attrs list. man ldapsearch: If no attrs are listed, all user attributes are returned. If only 1.1 is listed, no attributes will be returned. Regards On Mon, Jun 15, 2009 at 8:29 AM, Tihomir Culjaga <tculjaga@gmail.com <mailto:tculjaga@gmail.com>> wrote: Hello, maybe it is a dummy question but i'd like to know why i have so big discrepancy in execution between two apparently identical ldapsearch ? The 1st search takes 94 ms while the 2nd one only 7 ms. It doesn't matter how many times i execute the 1st search (meaning everytihng should be already cached) .. it is always the same. Does anyone know why? ~$ time ldapsearch -h localhost -x -b ou=redirecting,ou=Dir,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w **** uniqueID=38512303736 # extended LDIF # # LDAPv3 # base <ou=redirecting,ou=Dir,dc=ot,dc=hr> with scope subtree # filter: uniqueID=38512303736 # requesting: ALL # # 38512303736, redirecting, Dir, ot.hr <http://ot.hr> dn: uniqueID=38512303736,ou=redirecting,ou=Dir,dc=ot,dc=hr objectClass: top objectClass: uniqueID Prefix: 68A10 uniqueID: 38512303736 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 *real 0m0.094s* user 0m0.004s sys 0m0.000s ~$ time ldapsearch -h localhost -x -b ou=redirecting,ou=Dir,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w **** uniqueID=38515000400 # extended LDIF # # LDAPv3 # base <ou=redirecting,ou=Direktor,dc=ot,dc=hr> with scope subtree # filter: uniqueID=38515000400 # requesting: ALL # # 38515000400, redirecting, Dir, ot.hr <http://ot.hr> dn: uniqueID=38515000400,ou=redirecting,ou=Dir,dc=ot,dc=hr objectClass: top objectClass: uniqueID Prefix: 68B99 uniqueID: 38515000400 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 *real 0m0.007s* user 0m0.000s sys 0m0.004s tculjaga@l01sipindir2:~$