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
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@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org