On Tue, 2018-08-14 at 10:36 -0600, David Boreham wrote:
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).
There are other things to look at too. You have to look at the
lifecycle of IO. There are two main parts:.
Entries: Entry Cache <-> DB cache <-> Disk
Indexes: DB cache <-> Disk
The entry cache will keep copies of Slapi_Entry in the memory -
generally this is the biggest affect on performance. It prevents re-
accessing id2entry and performing the deserialisation process.
Deserialising entries is slow!!!
The db cache is caching writes and reads from the indexes and between
all the .db files. It can help speed up searches and more, but it's
affects are more limited compared to the entry cache.
Finally, if you are on a 1.3.7 release, you can consider *raising* your
idlscanlimit. 1.3.7 contains a filter optimisation step that means
idlscanlimit is now possibly slowing you down on certain searches,
rather than helping. I saw good results in benchmarks raising it to
99999999, but we did not yet make this a default as our team wanted
much more evidence and testing.
In same cases if your idlscanlimit is "low", this causes needless
access to the slapi-entries in the entry cache (and possible
eviction/inclusion), when accessing an index would be faster. If you
want to know more, I can write it up.
Finally, look at your thread count (newer 1.3.x should set this
automatically), to make sure you are getting good parallel throughput.
As with all changes, test and review to make sure it helps you in your
Today with 1.3.x we pushed to make many defaults "correct" out of box,
including autotuning backends and more. Perhaps consider using the
autotuning subsystem to help guide your decisions.
Hope that helps!
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html