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

Re: LDAP search question

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:~$