[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Index for objectclass does not work...
2011/1/3 Quanah Gibson-Mount <quanah@zimbra.com>:
>>> 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.
>>>
>>
>> But does the slapd process during this time _write_ (heavy the whole
>> time) to the disk?
>
> Did you configure you BDB backing cache to be in memory, or on disk? The
> default is for it to be on the disk. If you want it to be in memory, set an
> shm_key value in the database configuration.
>
> --Quanah
>
Yes, thanks, thats it :). But why are the shared Memory on disk? Does
it not make the slapd slower?
My second problem is, that I don't really understand, how indexes
work, or is the a problem with slapd, my configuration or my Database?
As I said in the message before,
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>"
Why does the it the search (hdbsearch) 430233 times, instead only
104384 times? I've also rebuild the index, should the index not only
return 104384 candidates?
Thanks for helping!
Kindly regards, Steeg