Hello again,
I can't solve my problem on my own... please help. As I can see at the moment, the Index for objectclass is not used.
The searchtime with and without index for objectclass is the same! The search looks like:
ldapsearch -x -h localhost -wpassword -D"uid=admin,ou=root" -b"cn=ownPath,ou=root" "(ObjectClass=subEngine)"
The first serach, it takes about 40seconds. So after the cache is filled, the next searches takes only about 2 seconds (during both logging is turned off!)... It doesn't matter whether the index is set up in the config or not.
To check, that the index is really set up (or not), I set loglevel 64 ind the slapd.conf: ####################################################################### @(#) $OpenLDAP: slapd 2.4.23 $#012#011opensuse-buildservice@opensuse.org line 30 (rootpw ***) line 31 (directory#011/var/lib/ldap_hdb) line 32 (logfile#011#011/var/log/openldap.log) line 33 (cachesize 1000000) line 34 (dncachesize 1000000) line 34 (idlcachesize 3000000) line 36 (dbnosync) line 38 (index objectClass eq) index objectClass 0x0004 line 39 (index cn eq,sub) index cn 0x0714 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapd starting #######################################################################
The searched objectClass=subEngine exists 104384 times in the entire directory: (=> ldapsearch -x -h localhost -D"uid=admin,ou=root" -b"cn=ou=root>" "(ObjectClass=subEngine)" dn | grep "^dn:" | wc -l)
If I configure with index for Objectclass, I get for the search following messages: ####################################################################### => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 470601 candidates <= bdb_equality_candidates: id=-1, first=228, last=470828 <= bdb_filter_candidates: id=-1 first=228 last=470828 <= bdb_list_candidates: id=-1 first=228 last=470828 <= bdb_filter_candidates: id=-1 first=228 last=470828 <= bdb_list_candidates: id=-1 first=40595 last=470828 <= bdb_filter_candidates: id=-1 first=40595 last=470828 bdb_search_candidates: id=-1 first=40595 last=470828 #######################################################################
If I search then in the logfile, I see 430233 messages like: "hdb_search: <candidate> <message: does not match filter | scope not okay>"
If I configure without index for objectclass, I get for the search following messages: ####################################################################### => bdb_equality_candidates (objectClass) <= bdb_equality_candidates: (objectClass) not indexed <= bdb_filter_candidates: id=-1 first=1 last=470828 <= bdb_list_candidates: id=-1 first=1 last=470828 <= bdb_filter_candidates: id=-1 first=1 last=470828 <= bdb_list_candidates: id=-1 first=40595 last=470828 <= bdb_filter_candidates: id=-1 first=40595 last=470828 bdb_search_candidates: id=-1 first=40595 last=470828 #######################################################################
During initial set up of the Database (slapadd, copied from production, off-line with slapcat), the index for objectclass was build. I also tried to rebuild the index with slapindex.
I configured a 64bit system, with 16GByte RAM and 2 CPUs under VMware ESX with own SAS-Storage (RAID10) for only this Machine.
The entire directory holds 470812 entires. (=> ldapsearch -x -h localhost -wpassword -D"uid=admin,ou=root" -b"ou=root" "(objectClass=*)" dn | grep "^dn:" | wc -l)
I configured slapd.conf as following: ####################################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/own.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/ldap moduleload back_hdb
sizelimit -1 timelimit 300 disallow bind_anon
gentlehup on tool-threads 2
# hdb database definitions
database hdb suffix "ou=root" rootdn "uid=admin,ou=root" checkpoint 4096 15 # loglevel only for test, not during time measuring loglevel 33 # or for config file processing # loglevel 64 rootpw password directory /var/lib/ldap_hdb logfile /var/log/openldap.log cachesize 1000000 dncachesize 1000000 idlcachesize 3000000 dbnosync
index objectClass,entryUUID,entryCSN eq index cn eq,sub #######################################################################
In DB_CONF I set 2GB BDB page cache (set_cachesize 2 0 1)
Thanks for help,
kindly regards Steeg
PS: During the first search, the disk is heavy used (iotop) by writing from slapd.conf ... why it - should only read ...? -
[...]
PS: During the first search, the disk is heavy used (iotop) by writing from slapd.conf ... why it - should only read ...?
This does not make sense. slapd should not *write* to slapd.conf.
You should probably learn how to use strace to find out what really happens on your system. You should also install the same LDAP database and the same config on another physical server to see whether it behaves equally there. If you can present proof that slapd is indeed writing to slapd.conf, you should probably file an ITS.
Good luck with your troubleshooting,
PS: During the first search, the disk is heavy used (iotop) by writing from slapd.conf ... why it - should only read ...?
This does not make sense. slapd should not *write* to slapd.conf.
Soryy, the correct sentence is: "During the first search, the disk is heavy used (seen with iotop) by writing from slapd, why - it should only read ...?" I apologizes for this mistake!
You should probably learn how to use strace to find out what really happens on your system.
I also used strace to catch the problem, but i did not find where the slapd write to disk. It seems, it comes via set up the futex write locks? I'm not a kernel programmer and the code from openldap is hard to read. But strace I use for several years to find errors, it was also the first choice for me, to find the error. It is not a normal file that will be written...
This behavior can be reproduce:
=> Large Database (eg. 500.000 objects/DN's) => put the one (same) Objectclass to >100.000 objects/DNs => turn of logging => start iotop (+ hit "o") => search for this objectclass and look what will happen during the first search with your disk
You should also install the same LDAP database and the same config on another physical server to see whether it behaves equally there.
I checked this problem on several machines, openldap versions (2.4.11, 2.4.21, 2.4.23) and Distribution (Debian 5, and Opensuse 11.1 and 11.3)
I investigated a lot time till now to find the error, but nothing helped ...
Good luck with your troubleshooting,
Thanks
--On Monday, January 03, 2011 9:22 PM +0100 Steeg Carson steeg.carson@googlemail.com wrote:
I also used strace to catch the problem, but i did not find where the slapd write to disk. It seems, it comes via set up the futex write locks? I'm not a kernel programmer and the code from openldap is hard to read. But strace I use for several years to find errors, it was also the first choice for me, to find the error. It is not a normal file that will be written...
The DB is always read off disk into the BDB backing cache the very first time slapd is run (assuming back-bdb or back-hdb are your backends). I don't see any bug/issue here.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org