[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: db_stat and back-bdb index question



--On Sunday, April 10, 2005 1:58 PM -0400 Adam Tauno Williams <adam@morrison-ind.com> wrote:

> http://www.openldap.org/faq/data/cache/1075.html contains the paragraph
> "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." Now I'm trying to match the phrases in that formulat to the
> output of db_stat -d (?) resulting from looking at an index file.
> Is -
> Number of hash buckets = "Number of tree internal pages."
> Numer of overflow pages = "Number of tree overflow pages."
> Number of duplicate pages = "Number of tree duplicate pages."
> Page Size = "Underlying database page size."
> - correct?  Or should I use some other parametet to db_stat when
> looking at these indexes (back-bdb)?
> Is this information correct for back-hdb as well?
What version of OpenLDAP are you using?
OpenLDAP moved to using B-trees with the OpenLDAP 2.2 release.


2.2.24; So is there still a formula to calculate an equivalent value in
2.2.x?

It honestly depends on what you want to do with DB_CONFIG. I prefer to make one large enough that my entire database fits into it. I don't know of any set formula for calculating the size it takes to do that. It depends on what indices you have, what type of indices you have, the data that's being indexed, and the size of your entries. I generally use slapadd to get an idea of how much cache is needed. If slapadd starts and then bogs down, you don't have enough. It is useful, at least for slapadd, to cache the entire database if possible, because slapadd slows to a crawl otherwise.

Other very important bits to tune outside of DB_CONFIG are the cachesize (how many of the most frequently accessed entries to hold onto) and idlcachesize (how many of the most frequently requested result sets of various filters to hold onto).

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin