While it is true that you want to have the highest possible hit ratio on
the two kinds of cache slapd maintains in order to achieve optimal read
performance, you _can_ simply configure quite small caches for slapd
(e.g. 1 few thousand entry cache and a few 100 MB DB cache) and rely on
the OS's filesystem cache and the relatively high speed of I/O these
days (SSDs...). This has the big advantage of removing the cognitive
load associated with setting the "correct" cache size.
On 8/14/2018 9:48 AM, Mark Reynolds wrote:
On 08/14/2018 11:32 AM, Paul Whitney wrote:
> Hi guys,
>
> Am looking to improve performance in my 389 DS deployment. In
> reviewing the documentation, the recommended size for the LDBM cache
> is the sum of the backend database + 15% of the backend database.
> For me that comes out to almost 27GB. Seems high considering the
> database cache is set very high as well. Is that a recommended
> setting or is there a better practice?
Well the more of the database you can keep in the cache the better the
performance. However, you are talking about the same cache: LDBM
cache is the same thing as the database cache.
But you should also include the entry cache for your database. So you
almost want to double that to 50GB total ;-) 27 GB for DB cache,
and 20 GB for entry cache (this varies of course for the entry cache
and it will probably be less than 20GB, but you won't know until you
start priming the entry cache and checking the database monitor -
trying to achieve 99% cache hit ratio).