[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
a few back-bdb tuning questions
- To: "OpenLDAP Software List" <openldap-software@OpenLDAP.org>
- Subject: a few back-bdb tuning questions
- From: "matthew sporleder" <msporleder@gmail.com>
- Date: Tue, 25 Apr 2006 09:04:45 -0400
- Content-disposition: inline
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tZMCBlp8EkOttjKYCdJIT0WbrQCUmjxQ5cZ4pAP4qeeHq0PV2Xw3tLs1b0gU7k6ApXq6ka1Qb16CRF2sU7S8Xz4/4r+vG7Ewp5tvgeyKxP7NFlisy8E5zN14k7giJqE/DaaL4F/MI6We3Xe1q48+sQHPHoo8QB+w2HIC1a1JglE=
I am using openldap 2.3.21 and bdb 4.4.20 (both compiled 64-bit) on solaris 10.
I followed (How do I determine the proper BDB/HDB database cache
size?) http://www.openldap.org/faq/data/cache/1075.html and saw the
note:
"I don't have enough free RAM to hold all the 800MB id2entry data, so
4MB is good enough."
And I found my number (around 30MB), which got me -great- read performance.
(so far I have my sun v120 upto 750+ BINDS/second using slamd and a
few thousand test accounts. Although, when I turned on logging, it
went down to 350/second)
Well.. what if you do have enough ram? Do you just set a huge cache
size, and it will eventually grab the whole thing? Do I need to
include my indexes and other things in that memory calculation, or
just the id2entry?
The man page mentions that hdb needs a very large idlcachesize
relative to the cachesize. What's the bdb recommendation on this?
When I checkpoint and use DB_LOG_AUTOREMOVE, what am I losing? The
old transactions that have already been written to the database on
disk? This would mean that my log.### are all active, correct? Since
the old ones would have been deleted.
And can multiple subordinate databases (I didn't find a lot of
documentation about subordinate, by the way. Shouldn't that be in
slapd.conf(5)?) share the same set_lg_dir? Or should they be
separated into directories of their own?
Thanks,
_Matt