[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: objectClass index from slapd.conf is not working
>>
>> I tried to increase the cachesize and idlcachesize to 100000 and
>> restarted the slapd, but it did not help.
>
> If you are using back-hdb, and using a subtree as the base (which it looked
> like you were doing), the first time through the search will be very slow
> while the cache is filled. That's a long-standing issue with back-hdb.
> Subsequent searches are substantially faster.
>
Thanks, but I use bdb as backend (see config). Due more investigation
today I find out, that if I use cachsize and idlcachsize about 500000
the second response (after first search) is quite faster, because now
the entries are cached. But by configuring an index for objectClass
it should avoid for searching all the entries?
This Configuration is not applicable at the moment, because my Linux
is 32bit (PAE) and the cachesize for the bdb-index is 1GByte. Slapd is
using about 2Gby of RAM at the moment.
But if I could increase the RAM, the problem of the index still exist.
In one of my DN (Container) are 88000 entires. I placed my search
there (searchBase) Only the Container itself has the searched
objectClass, but all entires in this container will be examined too.
Should the index for objectClass not only give back this _one_ (and
not 355545) Candidate, or do I misunderstood this?
==================================================
Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass)
Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates
==================================================
Thanks Tim