On Thu, 2017-11-16 at 21:59 -0600, Sergei Gerasenko wrote: > Hi William, > > 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. > > Got it. > > > > > > 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 > in general? 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 dc=example,dc=com. So we connect those "suffixes" with "mapping trees". Think "routers" 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: cd /var/lib/dirsrv/slapd-<inst>/db/userRoot dbscan -f id2entry.db | less You can see all the entries in the db "as they are stored" in the backend. 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% > > of > > the time. You really want this to be 85% or higher, else you are > > constantly importing/evicting from the entry cache. Every eviction > > and > > inclusion is costly as you have to-reread id2entry which is io > > intensive. > > > > I'd recommend increasing your entry cache size by double at a > > guess, > > 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 > > to > > 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 slow. 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!! > > Sergei > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
