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

dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config

_______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o rg

On Nov 16, 2017, at 9:37 PM, William Brown <wibrown(a)redhat.com&gt; 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(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave(a)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(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org>

On Nov 17, 2017, at 10:58 AM, Mark Reynolds <mreynolds(a)redhat.com&gt; 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

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 _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)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 _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o rg