...

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