This doesn't take into account other library overhead, so this is even lower
than the barest minimum. The default cache size, when nothing is configured,
...
...
@@ -263,8 +285,9 @@ id2entry data, so 4MB is good enough.
With back-bdb and back-hdb you can use "db_stat -m" to check how well the
database cache is performing.
For more information on {{db_stat}}: {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/utility/db_stat.html}}
H3: {{slapd}}(8) Entry Cache
H3: {{slapd}}(8) Entry Cache (cachesize)
The {{slapd}}(8) entry cache operates on decoded entries. The rationale - entries
in the entry cache can be used directly, giving the fastest response. If an entry
...
...
@@ -275,6 +298,10 @@ If the entry is in neither cache then BDB will have to flush some of its current
cached pages and bring in the needed pages, resulting in a couple of expensive
I/Os as well as parsing.
The most optimal value is of course, the entire number of entries in the database.
However, most directory servers don't consistently serve out their entire database, so setting this to a lesser number that more closely matches the believed working set of data is
sufficient. This is the second most important parameter for the DB.
As far as balancing the entry cache vs the BDB cache - parsed entries in memory
are generally about twice as large as they are on disk.
...
...
@@ -284,62 +311,27 @@ occurring in the database. It is merely the fact that the cache is thrashing
itself that causes performance/response time to slowdown.
MOVE BELOW AROUND:
If you want to setup the cache size, please read:
(Xref) How do I configure the BDB backend?
(Xref) What are the DB_CONFIG configuration directives?
