5:48 p.m.
BTW, Network is not the problem. I used private IP instead of DNS name
when connecting to LDAP server. The "ping" from the client to LDAP
server returned in <1ms.
Thanks!
--- On Thu, 9/11/08, Dieter Kluenter <dieter(a)dkluenter.de> wrote:
From: Dieter Kluenter <dieter(a)dkluenter.de>
Subject: Re: Help: Slow LDAP search with high %iowait
To: openldap-technical(a)openldap.org
Date: Thursday, September 11, 2008, 6:54 AM
Hi,
Victor <victorfuman(a)yahoo.com> writes:
Would you folks mind sharing some thoughts/ideas on this? Thanks a
lot!
--- On Mon, 9/8/08, Victor <victorfuman(a)yahoo.com> wrote:
> From: Victor <victorfuman(a)yahoo.com>
> Subject: Help: Slow LDAP search with high %iowait
> To: openldap-technical(a)openldap.org
> Date: Monday, September 8, 2008, 5:35 PM
> Hi ,
>
> I did quite a bit reading and research before I send email
> to this list for help. If I have missed some basic concepts
> here, please execuse my ignorance. Thanks for your help and
> time in advance.
did you read
http://www.openldap.org/faq/data/cache/1075.html
> 1. Summary
> The initial search in my prototyping with OpenLDAP (slapd +
> BDB) seemed to be slow. What is the reason and How could I
> fix it?
>
> 2. Configuration
> 2.1 Environment
> Linux CentOS, 1 hard disk (therefore unfortunately the BDB
> transaction logs and database files are written to the same
> disk), 120GB disk space (80% unused), 1GB RAM, reserved for
> this prototyping, OpenLDAP 2.3.39 with default BDB
> installation
add more RAM to your machine
> 2.2 slapd.conf (modified trivially for discussion
> purpose)
> # global configuration
> loglevel 0
>
> # BDB
> database bdb
> suffix "dc=test,dc=dummy,dc=com"
> rootdn
> "cn=Manager,dc=test,dc=dummy,dc=com"
> # Cleartext passwords, especially for the rootdn, should
> # be avoid. See slappasswd(8) and slapd.conf(5) for
> details.
> # Use of strong authentication encouraged.
> rootpw secret
> # The database directory MUST exist prior to running slapd
> AND
> # should only be accessible by the slapd and slap tools.
> # Mode 700 recommended.
> directory /usr/local/var/openldap-data
> #Other DB configuration
> idlcachesize 60000
> cachesize 20000
increase cachesize, add dncachsize, man slapd-bdb(5)
> # Indices to maintain
> # the indexes are to support search in first name, last
> name and email for both exact match and wild cards in the
> end
> index objectClass eq
> index gn pres,eq,sub
> index sn pres,eq,sub
> index mail pres,eq,sub
>
> 2.3 DB_CONFIG (for BDB)
> set_cachesize 0 52428800 1
> set_lg_bsize 2097512
> set_flags DB_LOG_AUTOREMOVE
> set_lg_regionmax 262144
increase cachesize
> 2.4 Data setup
> 2 million records (users with gn, sn, email, mobile, street
> address, etc. in the BDB; all records are indexed using the
> index in the above slapd.conf; grouped by the first
> character of lastName. For example,
> dn: ou=Z,dc=test,dc=dummy,dc=com
> objectclass: organizationalUnit
> ou: Z
> Sample LDIF entry:
> #Directory Entry
> dn:
> uid=ABCDEFGHIJKLMNOPQRSTUVWXYZ123459,ou=F,dc=test,dc=dummy,dc=com
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> uid: ABCDEFGHIJKLMNOPQRSTUVWXYZ123459
> ...... (details omitted)
What is the size of id2entry.bdb and all indexed >attribute>.bdb
> 3. Symptom/Problem
>
> It was very slow in the first (fresh) search if I searched
> by wildcard firstname only like "Larry*" (which
> returned 478 entries/users). The response time was generally
> higher than 5 seconds Depending the count of records found,
> the response time might exceed 20 or even 50 seconds. During
> the search, the "iostat" result showed +95%
> %iowait, await was much higher that svctm, the device %util
> was over 96%. Here is the "iostat" output:
This might depend on disk type, PATA vs. SATA, read ahead abilities
and so on.
> However, The subsequent search (using the exact search
> criteria) is much faster (within 200ms). I believe it is
> because of the cache.
200 ms is not fast enough, depending on network and server load,
respose values of 4 to 10 ms are reasonable.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E