Re: bdb corruption

[Matthew Schumacher <matt.s@aptalaska.net>]

Howard,

How did you find your hash buckets and over pages for the objectClass index?

My system returns:

#db_stat -d /usr/local/var/openldap-data/objectClass.bdb
53162   Btree magic number.
9       Btree version number.
Flags:  multiple-databases
2       Minimum keys per-page.
4096    Underlying database page size.
0       Number of levels in the tree.
0       Number of unique keys in the tree.
0       Number of data items in the tree.
0       Number of tree internal pages.
0       Number of bytes free in tree internal pages (0% ff).
0       Number of tree leaf pages.
0       Number of bytes free in tree leaf pages (0% ff).
0       Number of tree duplicate pages.
0       Number of bytes free in tree duplicate pages (0% ff).
0       Number of tree overflow pages.
0       Number of bytes free in tree overflow pages (0% ff).
0       Number of pages on the free list.

Does this mean that my system isn't using the index?  I have

index   objectClass     eq

in my slapd.conf.

Thanks


Howard Chu wrote:
> This 2.5MB number also doesn't take indexing into account. Each indexed
> attribute uses another database file of its own, using a Hash structure.
> Unlike the B-trees, where you only need to touch one data page to find an
> entry of interest, doing an index lookup generally touches multiple keys, and
> the point of a hash structure is that the keys are evenly distributed across
> the data space. That means there's no convenient compact subset of the
> database that you can keep in the cache to insure quick operation, you can
> pretty much expect references to be scattered across the whole thing. My
> strategy here would be to provide enough cache for at least 50% of all of the
> hash data. (Number of hash buckets + number of overflow pages + number of
> duplicate pages) * page size / 2.
>
> The objectClass index for my example database is 5.9MB and uses 3 hash
> buckets and 656 duplicate pages. So ( 3 + 656 ) * 4KB / 2 =~ 1.3MB.