On Thu, 2017-11-16 at 21:59 -0600, Sergei Gerasenko wrote:
Thanks much for the quick response! This is super helpful. I’m
attaching my cpu and meminfo info.
Sorry for the late response: was travelling,
> > dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
> ^ This monitors the general BDB performance.
> > dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config
> > dn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=config
> > dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> ^ These are monitors of unique suffixes and their indexes and other
> content like entrycaches that are per backend.
Cool. One question I’ve been meaning to ask — what’s under userRoot
So to really answer that I should explain the LDAP data model.
You have a set of objects, in a tree database. The RootDSE (you can
search with -b '' -s base by the way with ldapsearch) is the ... well,
root. Under than you have "suffixes", like dc=com and
So we connect those "suffixes" with "mapping trees". Think
that connect a suffix to a backend of some kind.
Then that backend stories entries: that's the "userRoot". It's a
backend which is connected by a mapping tree to route queries to it.
You can really get an idea of this by looking at what's in "userRoot".
If you look at:
dbscan -f id2entry.db | less
You can see all the entries in the db "as they are stored" in the
You'll notice some other .db files there too. These are the indexes to
make searching fast. That's another lesson in itself though :)
> > entrycachehitratio: 67
> ^ this 5 is super important. This is saying you have only hit 67%
> the time. You really want this to be 85% or higher, else you are
> constantly importing/evicting from the entry cache. Every eviction
> inclusion is costly as you have to-reread id2entry which is io
> I'd recommend increasing your entry cache size by double at a
> but I'd want to see your /proc/meminfo and /proc/cpuinfo to advise
> properly. I'd also need to see your ds version and userroot config
> really advise what changes to make.
Great info! I think we have plenty of RAM (64G) to make any
adjustment we want.
I’ve also heard of nsslapd-cachememsize — what does that control?
So getting entries from id2entry and deserialising them to Slapi_Entry
structures takes time. It locks the database and generally is a bit
So the entry cache stories Slapi_Entry structs "in memory" and keeps
them synced with id2entry. This way if a search needs an entry, it's
already there in memory ready to be accessed!
However, if it's no there, we need to lock id2entry, and read it,
deserialise it etc.
So having your entrycache "as large or larger" than id2entry.db is a
great idea, because then you never need to incur the performance
penalty of accessing id2entry.
Hope that helps,
Thanks so much, William!!
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
Red Hat, Australia/Brisbane