clarifications on cachesize, preferred db, et. al. from admin guide

[Tim Mooney <Tim.Mooney@ndsu.edu>]

All-

I'm getting back to the project of upgrading our OpenLDAP infrastructure,
which I started last summer but was interrupted by email outsourcing...

As things currently stand, I'll be deploying 2.4.25 + BDB 4.8.30 on RHEL
5.6.  I'm starting with a DB_CONFIG of

set_cachesize 0 536870912 1
set_lg_regionmax 262144
set_lg_bsize 2097152
set_flags DB_LOG_AUTOREMOVE

though I suspect I will tune further, as the servers are quite beefy and
our OpenLDAP databases are pretty modest (60K dn, 80 MB id2entry), so
we have horsepower and RAM to spare.

I've been carefully reviewing the docs and admin guide and have several
questions as points of clarification.

- Admin Guide, section 21.4.1.1.  The tuning chapter is a godsend and
the section on the calculations for Berkeley DB cache sizing is extremely
helpful, but I've noted that the docs indicate that each index is a hash
structure and proceed to describe how to calculate how much additional cache
you will want for each index you have, beyond what you need for the (Btree)
id2entry and dn2id.

Every single one of my index .bdb files is of type Btree, though, not
Hash.  Is that section of the docs outdated, and all indexed attributes
are now in Btree databases (for back-bdb and presumably back-hdb), or am
I fundamentally misunderstanding what the index-related cache calculations
are saying?

- Admin Guide, section 5.  The last note in the intro section of chapter
5 mentions that some backends and overlays do not support slapd-config,
without listing what those backends are.  Looking through the
documentation-related ITS's, it appears that at one point slapo-rwm didn't
support slapd-config, but that's apparently changed.

I realize it's more work to spell out what backends would prevent someone
from using slapd-config, especially since it must be kept up to date as
things change, but I think that explicitly listing the backends (and
overlays) that don't work with slapd-config will make people more likely
to choose slapd-config moving forward.  As things stand, most people
aren't going to know whether they can use slapd-config or not because
they don't know which backends work with it and which don't.

If you agree that it would be useful to explicitly list which backends
would block the use of slapd-config and someone can provide me with the
list of blockers, I would be happy to file an ITS and provide a patch to
the current docs to spell things out.  I personally think it will help
adoption of slapd-config.

- man page for slapd.backends(5).  The man page entry states that
bdb is the preferred backend.  I've seen enough hints and comments on
the mailing list to suggest that it will eventually be supplanted by hdb.
How soon is that going to happen (2.5?), and is it worth mentioning that
hdb is as good as bdb now and will be the new preferred backend soon?
Again, I'll submit the ITS with the doc patch if it's worth making that
assertion in the docs now.

- Admin Guide, chapter 21.  The tuning chapter doesn't mention the
potential benefits of using an alternate memory allocator on Linux, as
Quanah clued me in to on the mailing list last month.  Should it?  If
people feel it would be worthwhile to mention, I would be happy to write
the first draft and supply the patch in an ITS.

- Admin Guide, chapter 21.  The tuning chapter doesn't mention the
potential benefits of using sysv shared memory vs. mmap'ed files on
some platforms.  Should it?  Same offer for documentation patch applies,
though I expect this one will need more feedback from the experts.

Thanks,

Tim
--
Tim Mooney                                             Tim.Mooney@ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164