Hi,
I’ve been trying to estimate how optimal our settings are. I’ve read about the cn=monitor section and I see that there are several paths that have cn=monitor:
dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config 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
First question, what’s the difference between them?
Here’s the output of ldapsearch for the 1st and 4th variants. Does anybody see something abnormal?
------------------------------------------------------------------------------------------------ # => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’ ------------------------------------------------------------------------------------------------
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database readonly: 0 entrycachehits: 176959465 entrycachetries: 262445216 entrycachehitratio: 67 currententrycachesize: 10479044 maxentrycachesize: 10485760 currententrycachecount: 1409 maxentrycachecount: -1 dncachehits: 80627325 dncachetries: 80647850 dncachehitratio: 99 currentdncachesize: 1013607 maxdncachesize: 10485760 currentdncachecount: 9375 maxdncachecount: -1 normalizeddncachetries: 634018073 normalizeddncachehits: 633931903 normalizeddncachemisses: 86170 normalizeddncachehitratio: 99 currentnormalizeddncachesize: 19244372 maxnormalizeddncachesize: 20971520 currentnormalizeddncachecount: 86170 dbfilename-0: userRoot/nsds5ReplConflict.db dbfilecachehit-0: 0 dbfilecachemiss-0: 3 dbfilepagein-0: 3 dbfilepageout-0: 0 dbfilename-1: userRoot/memberOf.db dbfilecachehit-1: 188045 dbfilecachemiss-1: 4684 dbfilepagein-1: 4684 dbfilepageout-1: 1325 dbfilename-4: userRoot/cn.db dbfilecachehit-4: 234345675 dbfilecachemiss-4: 69406 dbfilepagein-4: 69406 dbfilepageout-4: 6967 dbfilename-7: userRoot/numsubordinates.db dbfilecachehit-7: 64 dbfilecachemiss-7: 143 dbfilepagein-7: 143 dbfilepageout-7: 148 dbfilename-8: userRoot/uid.db dbfilecachehit-8: 23978617 dbfilecachemiss-8: 15927 dbfilepagein-8: 15927 dbfilepageout-8: 38 dbfilename-9: userRoot/fqdn.db dbfilecachehit-9: 1719355 dbfilecachemiss-9: 187947 dbfilepagein-9: 187947 dbfilepageout-9: 440 dbfilename-10: userRoot/memberallowcmd.db dbfilecachehit-10: 1615 dbfilecachemiss-10: 492 dbfilepagein-10: 492 dbfilepageout-10: 0 dbfilename-11: userRoot/krbPrincipalName.db dbfilecachehit-11: 25458823 dbfilecachemiss-11: 484795 dbfilepagein-11: 484789 dbfilepageout-11: 9526 dbfilename-12: userRoot/member.db dbfilecachehit-12: 114136 dbfilecachemiss-12: 13041 dbfilepagein-12: 13041 dbfilepageout-12: 11865 dbfilename-13: userRoot/memberUser.db dbfilecachehit-13: 27275 dbfilecachemiss-13: 849 dbfilepagein-13: 849 dbfilepageout-13: 306 dbfilename-14: userRoot/nsuniqueid.db dbfilecachehit-14: 95501 dbfilecachemiss-14: 11980 dbfilepagein-14: 11980 dbfilepageout-14: 181 dbfilename-16: userRoot/mail.db dbfilecachehit-16: 196 dbfilecachemiss-16: 209 dbfilepagein-16: 209 dbfilepageout-16: 203 dbfilename-17: userRoot/parentid.db dbfilecachehit-17: 14494 dbfilecachemiss-17: 2956 dbfilepagein-17: 2956 dbfilepageout-17: 432 dbfilename-19: userRoot/givenName.db dbfilecachehit-19: 42 dbfilecachemiss-19: 44 dbfilepagein-19: 44 dbfilepageout-19: 38 dbfilename-20: userRoot/uidnumber.db dbfilecachehit-20: 711150 dbfilecachemiss-20: 12493 dbfilepagein-20: 12493 dbfilepageout-20: 5 dbfilename-21: userRoot/ipauniqueid.db dbfilecachehit-21: 38595230 dbfilecachemiss-21: 406501 dbfilepagein-21: 406501 dbfilepageout-21: 169 dbfilename-22: userRoot/ipasudorunasgroup.db dbfilecachehit-22: 812 dbfilecachemiss-22: 242 dbfilepagein-22: 242 dbfilepageout-22: 0 dbfilename-23: userRoot/objectclass.db dbfilecachehit-23: 1027902225 dbfilecachemiss-23: 49163 dbfilepagein-23: 49163 dbfilepageout-23: 3332 dbfilename-24: userRoot/memberdenycmd.db dbfilecachehit-24: 803 dbfilecachemiss-24: 251 dbfilepagein-24: 251 dbfilepageout-24: 0 dbfilename-25: userRoot/ipakrbprincipalalias.db dbfilecachehit-25: 7957213 dbfilecachemiss-25: 226 dbfilepagein-25: 226 dbfilepageout-25: 0 dbfilename-29: userRoot/id2entry.db dbfilecachehit-29: 255566500 dbfilecachemiss-29: 9612037 dbfilepagein-29: 9612016 dbfilepageout-29: 54967 dbfilename-30: userRoot/ancestorid.db dbfilecachehit-30: 21700375 dbfilecachemiss-30: 78004 dbfilepagein-30: 78004 dbfilepageout-30: 1112 dbfilename-31: userRoot/aci.db dbfilecachehit-31: 1 dbfilecachemiss-31: 2 dbfilepagein-31: 2 dbfilepageout-31: 0 dbfilename-32: userRoot/ipasudorunas.db dbfilecachehit-32: 1875 dbfilecachemiss-32: 512 dbfilepagein-32: 512 dbfilepageout-32: 18 dbfilename-33: userRoot/nscpEntryDN.db dbfilecachehit-33: 61 dbfilecachemiss-33: 68 dbfilepagein-33: 68 dbfilepageout-33: 69 dbfilename-35: userRoot/sn.db dbfilecachehit-35: 46 dbfilecachemiss-35: 52 dbfilepagein-35: 52 dbfilepageout-35: 46 dbfilename-36: userRoot/displayname.db dbfilecachehit-36: 95 dbfilecachemiss-36: 64 dbfilepagein-36: 64 dbfilepageout-36: 60 dbfilename-37: userRoot/userCertificate.db dbfilecachehit-37: 280 dbfilecachemiss-37: 183 dbfilepagein-37: 183 dbfilepageout-37: 109 dbfilename-38: userRoot/entryusn.db dbfilecachehit-38: 336424258 dbfilecachemiss-38: 39046 dbfilepagein-38: 39046 dbfilepageout-38: 10837 dbfilename-40: userRoot/krbCanonicalName.db dbfilecachehit-40: 17974 dbfilecachemiss-40: 8484 dbfilepagein-40: 8484 dbfilepageout-40: 7703 dbfilename-41: userRoot/managedby.db dbfilecachehit-41: 48870 dbfilecachemiss-41: 19625 dbfilepagein-41: 19625 dbfilepageout-41: 17508 dbfilename-42: userRoot/nsTombstoneCSN.db dbfilecachehit-42: 62 dbfilecachemiss-42: 66 dbfilepagein-42: 66 dbfilepageout-42: 68 dbfilename-43: userRoot/gidnumber.db dbfilecachehit-43: 2932108 dbfilecachemiss-43: 6784 dbfilepagein-43: 6784 dbfilepageout-43: 6 dbfilename-44: userRoot/entryrdn.db dbfilecachehit-44: 44453058 dbfilecachemiss-44: 176393 dbfilepagein-44: 176393 dbfilepageout-44: 1009 dbfilename-46: userRoot/memberservice.db dbfilecachehit-46: 485 dbfilecachemiss-46: 48 dbfilepagein-46: 48 dbfilepageout-46: 44 dbfilename-47: userRoot/memberHost.db dbfilecachehit-47: 98612 dbfilecachemiss-47: 8592 dbfilepagein-47: 8592 dbfilepageout-47: 1795
------------------------------------------------------------------------------------ # => 'cn=monitor,cn=ldbm database,cn=plugins,cn=config’ ------------------------------------------------------------------------------------
dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database dbcachehits: 2301984153 dbcachetries: 2314592529 dbcachehitratio: 99 dbcachepagein: 12608350 dbcachepageout: 426726 dbcacheroevict: 12463454 dbcacherwevict: 145594
On Thu, 2017-11-16 at 21:00 -0600, Sergei Gerasenko wrote:
Hi,
I’ve been trying to estimate how optimal our settings are. I’ve read about the cn=monitor section and I see that there are several paths that have cn=monitor:
These are all monitors for each database backend. So you have:
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.
So each of them can reveal different info.
BDB can show you about the interaction between DS and the BDB on disk. So this can have some IO related impact for *all* backends.
Then each backend monitor can help you understand the performance of indexes, entry cache and others. So let me help interpret yours:
First question, what’s the difference between them?
Here’s the output of ldapsearch for the 1st and 4th variants. Does anybody see something abnormal?
# => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database readonly: 0 entrycachehits: 176959465 entrycachetries: 262445216 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.
currententrycachesize: 10479044 maxentrycachesize: 10485760 currententrycachecount: 1409 maxentrycachecount: -1 dncachehits: 80627325 dncachetries: 80647850 dncachehitratio: 99
This number is good, what you want to see.
currentdncachesize: 1013607 maxdncachesize: 10485760 currentdncachecount: 9375 maxdncachecount: -1 normalizeddncachetries: 634018073 normalizeddncachehits: 633931903 normalizeddncachemisses: 86170 normalizeddncachehitratio: 99
Again, also good,
currentnormalizeddncachesize: 19244372 maxnormalizeddncachesize: 20971520 currentnormalizeddncachecount: 86170 dbfilename-0: userRoot/nsds5ReplConflict.db dbfilecachehit-0: 0 dbfilecachemiss-0: 3 dbfilepagein-0: 3 dbfilepageout-0: 0 dbfilename-1: userRoot/memberOf.db dbfilecachehit-1: 188045 dbfilecachemiss-1: 4684 dbfilepagein-1: 4684 dbfilepageout-1: 1325 dbfilename-4: userRoot/cn.db dbfilecachehit-4: 234345675 dbfilecachemiss-4: 69406 dbfilepagein-4: 69406 dbfilepageout-4: 6967 dbfilename-7: userRoot/numsubordinates.db dbfilecachehit-7: 64 dbfilecachemiss-7: 143 dbfilepagein-7: 143 dbfilepageout-7: 148 dbfilename-8: userRoot/uid.db dbfilecachehit-8: 23978617 dbfilecachemiss-8: 15927 dbfilepagein-8: 15927 dbfilepageout-8: 38 dbfilename-9: userRoot/fqdn.db dbfilecachehit-9: 1719355 dbfilecachemiss-9: 187947 dbfilepagein-9: 187947 dbfilepageout-9: 440 dbfilename-10: userRoot/memberallowcmd.db dbfilecachehit-10: 1615 dbfilecachemiss-10: 492 dbfilepagein-10: 492 dbfilepageout-10: 0 dbfilename-11: userRoot/krbPrincipalName.db dbfilecachehit-11: 25458823 dbfilecachemiss-11: 484795 dbfilepagein-11: 484789 dbfilepageout-11: 9526 dbfilename-12: userRoot/member.db dbfilecachehit-12: 114136 dbfilecachemiss-12: 13041 dbfilepagein-12: 13041 dbfilepageout-12: 11865 dbfilename-13: userRoot/memberUser.db dbfilecachehit-13: 27275 dbfilecachemiss-13: 849 dbfilepagein-13: 849 dbfilepageout-13: 306 dbfilename-14: userRoot/nsuniqueid.db dbfilecachehit-14: 95501 dbfilecachemiss-14: 11980 dbfilepagein-14: 11980 dbfilepageout-14: 181 dbfilename-16: userRoot/mail.db dbfilecachehit-16: 196 dbfilecachemiss-16: 209 dbfilepagein-16: 209 dbfilepageout-16: 203 dbfilename-17: userRoot/parentid.db dbfilecachehit-17: 14494 dbfilecachemiss-17: 2956 dbfilepagein-17: 2956 dbfilepageout-17: 432 dbfilename-19: userRoot/givenName.db dbfilecachehit-19: 42 dbfilecachemiss-19: 44 dbfilepagein-19: 44 dbfilepageout-19: 38 dbfilename-20: userRoot/uidnumber.db dbfilecachehit-20: 711150 dbfilecachemiss-20: 12493 dbfilepagein-20: 12493 dbfilepageout-20: 5 dbfilename-21: userRoot/ipauniqueid.db dbfilecachehit-21: 38595230 dbfilecachemiss-21: 406501 dbfilepagein-21: 406501 dbfilepageout-21: 169 dbfilename-22: userRoot/ipasudorunasgroup.db dbfilecachehit-22: 812 dbfilecachemiss-22: 242 dbfilepagein-22: 242 dbfilepageout-22: 0 dbfilename-23: userRoot/objectclass.db dbfilecachehit-23: 1027902225 dbfilecachemiss-23: 49163 dbfilepagein-23: 49163 dbfilepageout-23: 3332 dbfilename-24: userRoot/memberdenycmd.db dbfilecachehit-24: 803 dbfilecachemiss-24: 251 dbfilepagein-24: 251 dbfilepageout-24: 0 dbfilename-25: userRoot/ipakrbprincipalalias.db dbfilecachehit-25: 7957213 dbfilecachemiss-25: 226 dbfilepagein-25: 226 dbfilepageout-25: 0 dbfilename-29: userRoot/id2entry.db dbfilecachehit-29: 255566500 dbfilecachemiss-29: 9612037 dbfilepagein-29: 9612016 dbfilepageout-29: 54967 dbfilename-30: userRoot/ancestorid.db dbfilecachehit-30: 21700375 dbfilecachemiss-30: 78004 dbfilepagein-30: 78004 dbfilepageout-30: 1112 dbfilename-31: userRoot/aci.db dbfilecachehit-31: 1 dbfilecachemiss-31: 2 dbfilepagein-31: 2 dbfilepageout-31: 0 dbfilename-32: userRoot/ipasudorunas.db dbfilecachehit-32: 1875 dbfilecachemiss-32: 512 dbfilepagein-32: 512 dbfilepageout-32: 18 dbfilename-33: userRoot/nscpEntryDN.db dbfilecachehit-33: 61 dbfilecachemiss-33: 68 dbfilepagein-33: 68 dbfilepageout-33: 69 dbfilename-35: userRoot/sn.db dbfilecachehit-35: 46 dbfilecachemiss-35: 52 dbfilepagein-35: 52 dbfilepageout-35: 46 dbfilename-36: userRoot/displayname.db dbfilecachehit-36: 95 dbfilecachemiss-36: 64 dbfilepagein-36: 64 dbfilepageout-36: 60 dbfilename-37: userRoot/userCertificate.db dbfilecachehit-37: 280 dbfilecachemiss-37: 183 dbfilepagein-37: 183 dbfilepageout-37: 109 dbfilename-38: userRoot/entryusn.db dbfilecachehit-38: 336424258 dbfilecachemiss-38: 39046 dbfilepagein-38: 39046 dbfilepageout-38: 10837 dbfilename-40: userRoot/krbCanonicalName.db dbfilecachehit-40: 17974 dbfilecachemiss-40: 8484 dbfilepagein-40: 8484 dbfilepageout-40: 7703 dbfilename-41: userRoot/managedby.db dbfilecachehit-41: 48870 dbfilecachemiss-41: 19625 dbfilepagein-41: 19625 dbfilepageout-41: 17508 dbfilename-42: userRoot/nsTombstoneCSN.db dbfilecachehit-42: 62 dbfilecachemiss-42: 66 dbfilepagein-42: 66 dbfilepageout-42: 68 dbfilename-43: userRoot/gidnumber.db dbfilecachehit-43: 2932108 dbfilecachemiss-43: 6784 dbfilepagein-43: 6784 dbfilepageout-43: 6 dbfilename-44: userRoot/entryrdn.db dbfilecachehit-44: 44453058 dbfilecachemiss-44: 176393 dbfilepagein-44: 176393 dbfilepageout-44: 1009 dbfilename-46: userRoot/memberservice.db dbfilecachehit-46: 485 dbfilecachemiss-46: 48 dbfilepagein-46: 48 dbfilepageout-46: 44 dbfilename-47: userRoot/memberHost.db dbfilecachehit-47: 98612 dbfilecachemiss-47: 8592 dbfilepagein-47: 8592 dbfilepageout-47: 1795
# => 'cn=monitor,cn=ldbm database,cn=plugins,cn=config’
dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database dbcachehits: 2301984153 dbcachetries: 2314592529 dbcachehitratio: 99 dbcachepagein: 12608350 dbcachepageout: 426726 dbcacheroevict: 12463454 dbcacherwevict: 145594
This one looks great! 99% hit ratio means you have most of your data in ram, good access pattens. you have some evictions but not many, so this setting is probably happy :)
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
Hi William,
Thanks much for the quick response! This is super helpful. I’m attaching my cpu and meminfo info.
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?
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?
Thanks so much, William!!
Sergei
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
Hi William,
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.
Confirmed
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.
Ok, so when issue requests for entries under dc=example,dc=com and they get translated by a mapping tree to a physical db file. I noticed that if I specify the base dn as “cn=config”, I don’t see user account data for example. When I bind under “dc=example,dc=com” however, I do! Is that because when I bind under cn=config, I don’t go through a mapping tree, but when I bind with "dc=example,dc=com” I do? I of course use our company name instead of “dc=example,dc=com”.
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
Nice
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.
Great info again. Quick question though. There are at least two types of cache I’ve seen: the entry cache, and the dn cache. I think the entry cache corresponds to id2entry.db, right? What corresponds to the dn cache?
Also: do ipa services need to be stopped when using the ipa-backup utility?
Thanks again, Sergei
On Mon, 2017-11-20 at 09:42 -0600, Sergei Gerasenko wrote:
Hi William,
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.
Confirmed
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.
Ok, so when issue requests for entries under dc=example,dc=com and they get translated by a mapping tree to a physical db file. I noticed that if I specify the base dn as “cn=config”, I don’t see user account data for example. When I bind under “dc=example,dc=com” however, I do! Is that because when I bind under cn=config, I don’t go through a mapping tree, but when I bind with "dc=example,dc=com” I do? I of course use our company name instead of “dc=example,dc=com”.
cn=config is special, that's why :) You should generally ignore it for these discussions about backends and databases.
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
Nice
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.
Great info again. Quick question though. There are at least two types of cache I’ve seen: the entry cache, and the dn cache. I think the entry cache corresponds to id2entry.db, right? What corresponds to the dn cache?
So if you look at the entries from id2entry you'll notice that they don't have dn's rdns. IE:
uid=william
Rather than:
uid=william,ou=People,....
So the entries in id2entry are just the "objects". They are associated into a tree by the parentid attribute. So for example:
dc=example,dc=com entryid: 1
ou=People parentid: 1 entryid: 2
So ou=People has a parent of "entry 1".
The dncache exists to cache these relation ships: because we have to "walk up" a number of entries to work out entryid -> dn, it's better to cache this result if we can. Again, this saves accessing id2entry, which can be a costly operation.
So here, we'd cache entryid: 2 with a dn of ou=People,dc=example,dc=com
Does that help?
Also: do ipa services need to be stopped when using the ipa-backup utility?
I can't answer that I have not used IPA in many years. Please ask the freeipa-users list for help on that topic, or refer to the documentation on access.redhat.com (redhat IDM correlates to FreeIPA).
Thanks again, Sergei _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
cn=config is special, that's why :) You should generally ignore it for these discussions about backends and databases.
not to annoy, but what’s special about it? A quick question about the terminology: what’s a backend? The physical db files on disk?
So if you look at the entries from id2entry you'll notice that they don't have dn's rdns. IE:
uid=william
Does that help?
Well explained. Thank you!
So what are the rules of thumb for choosing the sizes of these databases? Currently, I just set both cache sizes to 3G because I have the memory.
Here’s my emergency ldif for now:
dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dncachememsize nsslapd-dncachememsize: 3000000000 - replace: nsslapd-cachememsize nsslapd-cachememsize: 3000000000
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dncachememsize nsslapd-dncachememsize: 3000000000 - replace: nsslapd-cachememsize nsslapd-cachememsize: 3000000000
I will configure auto cache resizing later. Do I need to restart the service after the change?
Thanks, Sergei
On Nov 16, 2017, at 9:37 PM, William Brown wibrown@redhat.com wrote:
On Thu, 2017-11-16 at 21:00 -0600, Sergei Gerasenko wrote:
Hi,
I’ve been trying to estimate how optimal our settings are. I’ve read about the cn=monitor section and I see that there are several paths that have cn=monitor:
These are all monitors for each database backend. So you have:
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.
So each of them can reveal different info.
BDB can show you about the interaction between DS and the BDB on disk. So this can have some IO related impact for *all* backends.
Then each backend monitor can help you understand the performance of indexes, entry cache and others. So let me help interpret yours:
First question, what’s the difference between them?
Here’s the output of ldapsearch for the 1st and 4th variants. Does anybody see something abnormal?
# => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database readonly: 0 entrycachehits: 176959465 entrycachetries: 262445216 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.
currententrycachesize: 10479044 maxentrycachesize: 10485760 currententrycachecount: 1409 maxentrycachecount: -1 dncachehits: 80627325 dncachetries: 80647850 dncachehitratio: 99
This number is good, what you want to see.
currentdncachesize: 1013607 maxdncachesize: 10485760 currentdncachecount: 9375 maxdncachecount: -1 normalizeddncachetries: 634018073 normalizeddncachehits: 633931903 normalizeddncachemisses: 86170 normalizeddncachehitratio: 99
Again, also good,
currentnormalizeddncachesize: 19244372 maxnormalizeddncachesize: 20971520 currentnormalizeddncachecount: 86170 dbfilename-0: userRoot/nsds5ReplConflict.db dbfilecachehit-0: 0 dbfilecachemiss-0: 3 dbfilepagein-0: 3 dbfilepageout-0: 0 dbfilename-1: userRoot/memberOf.db dbfilecachehit-1: 188045 dbfilecachemiss-1: 4684 dbfilepagein-1: 4684 dbfilepageout-1: 1325 dbfilename-4: userRoot/cn.db dbfilecachehit-4: 234345675 dbfilecachemiss-4: 69406 dbfilepagein-4: 69406 dbfilepageout-4: 6967 dbfilename-7: userRoot/numsubordinates.db dbfilecachehit-7: 64 dbfilecachemiss-7: 143 dbfilepagein-7: 143 dbfilepageout-7: 148 dbfilename-8: userRoot/uid.db dbfilecachehit-8: 23978617 dbfilecachemiss-8: 15927 dbfilepagein-8: 15927 dbfilepageout-8: 38 dbfilename-9: userRoot/fqdn.db dbfilecachehit-9: 1719355 dbfilecachemiss-9: 187947 dbfilepagein-9: 187947 dbfilepageout-9: 440 dbfilename-10: userRoot/memberallowcmd.db dbfilecachehit-10: 1615 dbfilecachemiss-10: 492 dbfilepagein-10: 492 dbfilepageout-10: 0 dbfilename-11: userRoot/krbPrincipalName.db dbfilecachehit-11: 25458823 dbfilecachemiss-11: 484795 dbfilepagein-11: 484789 dbfilepageout-11: 9526 dbfilename-12: userRoot/member.db dbfilecachehit-12: 114136 dbfilecachemiss-12: 13041 dbfilepagein-12: 13041 dbfilepageout-12: 11865 dbfilename-13: userRoot/memberUser.db dbfilecachehit-13: 27275 dbfilecachemiss-13: 849 dbfilepagein-13: 849 dbfilepageout-13: 306 dbfilename-14: userRoot/nsuniqueid.db dbfilecachehit-14: 95501 dbfilecachemiss-14: 11980 dbfilepagein-14: 11980 dbfilepageout-14: 181 dbfilename-16: userRoot/mail.db dbfilecachehit-16: 196 dbfilecachemiss-16: 209 dbfilepagein-16: 209 dbfilepageout-16: 203 dbfilename-17: userRoot/parentid.db dbfilecachehit-17: 14494 dbfilecachemiss-17: 2956 dbfilepagein-17: 2956 dbfilepageout-17: 432 dbfilename-19: userRoot/givenName.db dbfilecachehit-19: 42 dbfilecachemiss-19: 44 dbfilepagein-19: 44 dbfilepageout-19: 38 dbfilename-20: userRoot/uidnumber.db dbfilecachehit-20: 711150 dbfilecachemiss-20: 12493 dbfilepagein-20: 12493 dbfilepageout-20: 5 dbfilename-21: userRoot/ipauniqueid.db dbfilecachehit-21: 38595230 dbfilecachemiss-21: 406501 dbfilepagein-21: 406501 dbfilepageout-21: 169 dbfilename-22: userRoot/ipasudorunasgroup.db dbfilecachehit-22: 812 dbfilecachemiss-22: 242 dbfilepagein-22: 242 dbfilepageout-22: 0 dbfilename-23: userRoot/objectclass.db dbfilecachehit-23: 1027902225 dbfilecachemiss-23: 49163 dbfilepagein-23: 49163 dbfilepageout-23: 3332 dbfilename-24: userRoot/memberdenycmd.db dbfilecachehit-24: 803 dbfilecachemiss-24: 251 dbfilepagein-24: 251 dbfilepageout-24: 0 dbfilename-25: userRoot/ipakrbprincipalalias.db dbfilecachehit-25: 7957213 dbfilecachemiss-25: 226 dbfilepagein-25: 226 dbfilepageout-25: 0 dbfilename-29: userRoot/id2entry.db dbfilecachehit-29: 255566500 dbfilecachemiss-29: 9612037 dbfilepagein-29: 9612016 dbfilepageout-29: 54967 dbfilename-30: userRoot/ancestorid.db dbfilecachehit-30: 21700375 dbfilecachemiss-30: 78004 dbfilepagein-30: 78004 dbfilepageout-30: 1112 dbfilename-31: userRoot/aci.db dbfilecachehit-31: 1 dbfilecachemiss-31: 2 dbfilepagein-31: 2 dbfilepageout-31: 0 dbfilename-32: userRoot/ipasudorunas.db dbfilecachehit-32: 1875 dbfilecachemiss-32: 512 dbfilepagein-32: 512 dbfilepageout-32: 18 dbfilename-33: userRoot/nscpEntryDN.db dbfilecachehit-33: 61 dbfilecachemiss-33: 68 dbfilepagein-33: 68 dbfilepageout-33: 69 dbfilename-35: userRoot/sn.db dbfilecachehit-35: 46 dbfilecachemiss-35: 52 dbfilepagein-35: 52 dbfilepageout-35: 46 dbfilename-36: userRoot/displayname.db dbfilecachehit-36: 95 dbfilecachemiss-36: 64 dbfilepagein-36: 64 dbfilepageout-36: 60 dbfilename-37: userRoot/userCertificate.db dbfilecachehit-37: 280 dbfilecachemiss-37: 183 dbfilepagein-37: 183 dbfilepageout-37: 109 dbfilename-38: userRoot/entryusn.db dbfilecachehit-38: 336424258 dbfilecachemiss-38: 39046 dbfilepagein-38: 39046 dbfilepageout-38: 10837 dbfilename-40: userRoot/krbCanonicalName.db dbfilecachehit-40: 17974 dbfilecachemiss-40: 8484 dbfilepagein-40: 8484 dbfilepageout-40: 7703 dbfilename-41: userRoot/managedby.db dbfilecachehit-41: 48870 dbfilecachemiss-41: 19625 dbfilepagein-41: 19625 dbfilepageout-41: 17508 dbfilename-42: userRoot/nsTombstoneCSN.db dbfilecachehit-42: 62 dbfilecachemiss-42: 66 dbfilepagein-42: 66 dbfilepageout-42: 68 dbfilename-43: userRoot/gidnumber.db dbfilecachehit-43: 2932108 dbfilecachemiss-43: 6784 dbfilepagein-43: 6784 dbfilepageout-43: 6 dbfilename-44: userRoot/entryrdn.db dbfilecachehit-44: 44453058 dbfilecachemiss-44: 176393 dbfilepagein-44: 176393 dbfilepageout-44: 1009 dbfilename-46: userRoot/memberservice.db dbfilecachehit-46: 485 dbfilecachemiss-46: 48 dbfilepagein-46: 48 dbfilepageout-46: 44 dbfilename-47: userRoot/memberHost.db dbfilecachehit-47: 98612 dbfilecachemiss-47: 8592 dbfilepagein-47: 8592 dbfilepageout-47: 1795
# => 'cn=monitor,cn=ldbm database,cn=plugins,cn=config’
dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database dbcachehits: 2301984153 dbcachetries: 2314592529 dbcachehitratio: 99 dbcachepagein: 12608350 dbcachepageout: 426726 dbcacheroevict: 12463454 dbcacherwevict: 145594
This one looks great! 99% hit ratio means you have most of your data in ram, good access pattens. you have some evictions but not many, so this setting is probably happy :)
389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o mailto:389-users-leave@lists.fedoraproject.o rg
-- Sincerely,
William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
On 11/17/2017 11:45 AM, Sergei Gerasenko wrote:
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dncachememsize nsslapd-dncachememsize: 3000000000
replace: nsslapd-cachememsize nsslapd-cachememsize: 3000000000
After these changes you do need to restart
Thanks, Mark!!
On Nov 17, 2017, at 10:58 AM, Mark Reynolds mreynolds@redhat.com wrote:
On 11/17/2017 11:45 AM, Sergei Gerasenko wrote:
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dncachememsize nsslapd-dncachememsize: 3000000000
replace: nsslapd-cachememsize nsslapd-cachememsize: 3000000000
After these changes you do need to restart
The change went in and the machine’s cache rate is currently at 91. woot!
On Nov 17, 2017, at 11:46 AM, Sergei Gerasenko gerases@gmail.com wrote:
Thanks, Mark!!
On Nov 17, 2017, at 10:58 AM, Mark Reynolds <mreynolds@redhat.com mailto:mreynolds@redhat.com> wrote:
On 11/17/2017 11:45 AM, Sergei Gerasenko wrote:
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dncachememsize nsslapd-dncachememsize: 3000000000
replace: nsslapd-cachememsize nsslapd-cachememsize: 3000000000
After these changes you do need to restart
389-users@lists.fedoraproject.org
-
Mark Reynolds -
Sergei Gerasenko -
William Brown