I've always wondered why Netscape DS (and its offspring) separated the
import cache (slapadd) from the cache used by the running process (slapd,
slapcat, etc). In doing some benchmarking of slapd, I understand the
reasoning now. Essentially, the BDB Cache is heavily used by slapadd, but
it isn't noticeably used at all by the other slap* functions that I tested.
I wonder if it may be useful to pursue a similar configuration setting with
OpenLDAP, because when you are dealing in environments where you only have
some X amount of memory, it is then advantageous to fully utilize it for an
import, and then drop it down to a very small amount for the running slapd
process, and instead bump up your entry/idl caches instead. I'm
particularly thinking of systems where you need some 256GB to slapadd the
DB (say a 50 million entry DB), and also want decent performance from the
running process (a good size entry/idl cache). This would easily allow the
flexibility, without having to manually go and hack DB_CONFIG and then
recreate the DB environment all the time.
--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
