Re: slapd index and db errs crashing frequently (ITS#309)

[Kurt@OpenLDAP.org]

At 06:10 PM 9/27/99 GMT, ngs@elok.com wrote:
>>
>>
>> With 150K entries, a DN sub index could be quite large,
>> though ALLIDS blocks should keep it from getting out of hand.
>> You can try:
>>         1) lowering SLAPD_LDBM_MIN_MAXIDS
>>         2) hack the "sub," out of back-ldbm/init.c dn
>>         initialization.
>
>ALLIDS has always been a problem for me due to the nature of the data I
>work with. The data set is large and
>there are generally very simple differentiating attributes, male/female,
>age, interests etc. This meant that I
>found virtually every useful attribute/value that is indexed exceeding
>the ALLIDS threshold and my searches were
>taking forever.

Which, of course, makes them quite pointless to index.

>Something that would help me to solve this particular problem would be
>to understand whether the server
>re-orders the LDAP query terms at all in order to optimize the search,
>or whether it follows the order of the
>terms in the query string.

The server doesn't reorder the filter.  It first does index
lookups for each subfilter and combined the index information
into a list of entries to test.

>For example - if the Person value for objectclass has exceeded the
>ALLIDs threshold, but the Male value for
>gender has not, will a search (&(objectlass=Person)(gender=male)) search
>every entry while
>(&(gender=male)(objectclass=Person)) will take advantage of the index to
>short circuit the search?

Since both are likely ALLIDs the order doesn't really
matter.  The intersection would be ALLIDs, hence all
entries being tested for the condition.

For indexing to be of any value, one of the ANDed
attribute value assertions needs to return a non-ALLIDs
index.

>> >Sep 27 15:26:46 work slapd[18596]: ldbm_db_errcall(): ==>
>> >/disk2/p2-overflow/slapd/db.new/dn.dbb: page 1347241258 doesn't
>exist, create
>> >flag not set
>> Did you run out of disk space (or quota)?
>Very unlikely.

Others have reported similiar error messages.  I am not sure
of the cause.

>You wouldn't have the 2.7.5 tar.gz file would you?

Not handy.  You might find it on ftp.cdrom.com or other archive site.

>Incidentally, in the same situation as the above (slapd 1.2.7 + DB
>2.7.7) I tried to use the readonly command in
>the slapd.conf file and it didn't seem to have any effect - I could
>modify entries at will. Is it meant to work?

I suspect so.

>Does it apply to the rootdn as well?

Not sure.  I'd have to look at the code.  I generally use ACLs
to limit access.

	Kurt