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