4 Replies Latest reply on Aug 27, 2014 11:37 AM by 835163

    dbcacheroevict and dbcacherwevict


      I am looking for some more details about dbcacheroevict and dbcacherwevict as they relate to caching in ODSEE.  The documentation I have found describes them as follows:



      This attribute shows the clean pages forced from the cache.


      This attribute shows the dirty pages forced from the cache.


      It also states the lower the number, the better.  Does that mean for a well performing directory instance these should run close to zero?


      If my values for these two instances are higher than they should be, does that simply mean my cache is not big enough?  Or, is there much more that needs to be considered.


      Here is an example of what one of my instances looks like currently:


      # monitor, ldbm database, plugins, config

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

      objectClass: top

      objectClass: extensibleObject

      cn: monitor

      database: ldbm database

      dbcachehits: 215730683

      dbcachetries: 228166376

      dbcachehitratio: 94

      dbcachepagein: 12435697

      dbcachepageout: 1415074

      dbcacheroevict: 12269441

      dbcacherwevict: 293


      Thank you in advance!

        • 1. Re: dbcacheroevict and dbcacherwevict
          Sylvain Duloutre-Oracle



          The fact that values are not close to 0 means that the cache is not big enough to hold  _all_ the data, so at some point

          some pages must be cleaned.  However a cache hit ration of 94% is quite good and increasing the cache size may not really

          improve DS performances significantly. Are you facing perfs issues ?


          PS: FYI, These values correspond to the st_ro_evict and st_rw_evict fields in Berkelet db memory pool statistics:






          When closing a thread as answered remember to mark the correct and helpful posts to make it easier for others to find them

          • 2. Re: dbcacheroevict and dbcacherwevict



            Thank you for your reply.  We experience performance issues which are sporadic in nature.  When we have an issue we usually have a large spike in connections and readwaiters (instances are fronted with OVD and we suspect retries are playing a part).  We have a had a difficult time pinpointing the issue and thus we are exploring many avenues including the Java code calling the directory server.  The reason I started looking at these two attributes is because they stuck out when comparing this instance to one that we do not see the issue on (the two instances are configured exactly the same but serve different lines of business).  I am going to throw another snapshot of the cn=monitor data in from a few minutes ago in case it might help.


            nsslapd-db-cache-region-wait-rate stands out to me, but I have yet to find much more than a definition for this attribute.




            # monitor, ldbm database, plugins, config

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

            objectClass: top

            objectClass: extensibleObject

            cn: monitor

            database: ldbm database

            dbcachehits: 296196826

            dbcachetries: 307853689

            dbcachehitratio: 96

            dbcachepagein: 11656864

            dbcachepageout: 1308617

            dbcacheroevict: 11351850

            dbcacherwevict: 151



            # database, monitor, ldbm database, plugins, config

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

            objectClass: top

            objectClass: extensibleObject

            cn: database

            nsslapd-db-abort-rate: 4902691

            nsslapd-db-configured-txns: 210

            nsslapd-db-active-txns: 0

            nsslapd-db-max-txns: 2

            nsslapd-db-cache-hit: 296196826

            nsslapd-db-cache-try: 307853689

            nsslapd-db-cache-region-wait-rate: 173110

            nsslapd-db-cache-size-bytes: 2621440000

            nsslapd-db-clean-pages: 312975

            nsslapd-db-commit-rate: 2364668

            nsslapd-db-deadlock-rate: 31

            nsslapd-db-dirty-pages: 381

            nsslapd-db-hash-buckets: 262147

            nsslapd-db-hash-elements-examine-rate: 611994365

            nsslapd-db-hash-search-rate: 319887009

            nsslapd-db-lock-conflicts: 111277

            nsslapd-db-lock-region-wait-rate: 0

            nsslapd-db-lock-request-rate: 287254291

            nsslapd-db-lockers: 241

            nsslapd-db-configured-locks: 20000

            nsslapd-db-current-locks: 77

            nsslapd-db-max-locks: 2518

            nsslapd-db-log-bytes-since-checkpoint: 2440210

            nsslapd-db-log-region-wait-rate: 2866

            nsslapd-db-log-write-rate: 1868990984

            nsslapd-db-log-write-count: 107679

            nsslapd-db-log-write-count-fill: 85

            nsslapd-db-log-flush-count: 107594

            nsslapd-db-log-flush-commit: 107594

            nsslapd-db-log-max-commit-per-flush: 0

            nsslapd-db-log-min-commit-per-flush: 0

            nsslapd-db-longest-chain-length: 6

            nsslapd-db-page-create-rate: 12992

            nsslapd-db-page-read-rate: 11656864

            nsslapd-db-page-ro-evict-rate: 11351850

            nsslapd-db-page-rw-evict-rate: 151

            nsslapd-db-page-trickle-rate: 0

            nsslapd-db-page-write-rate: 1308617

            nsslapd-db-pages-in-use: 313356

            nsslapd-db-txn-region-wait-rate: 472

            • 3. Re: dbcacheroevict and dbcacherwevict



              Hope you've already compared the Java version between the problematic OVD and the other one. ? If no, can you let us know what are those if they differ?



              • 4. Re: dbcacheroevict and dbcacherwevict


                Java(TM) SE Runtime Environment (build 1.6.0_37-b06)

                Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)



                Java(TM) SE Runtime Environment (build 1.6.0_21-b06)

                Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)


                Since my last post I realized that my entrycachehitratio was around 57% and that we were reaching our set maxentrycachesize (which was 17G).  I have since upped that to 20G and watched our currententrycachesize grow to 17.7G in almost 24hrs.  The entrycachehitratio is up to 62% and I expect it to get higher.


                I am still curious about nsslapd-db-cache-region-wait-rate - This attribute shows the number of times that a thread of control was forced to wait before obtaining the region lock (per www.centos.org).  This instance that has performance issues has a value of 203221, which is up from my previous post.  An instance that is configured similarly but consumed by different business line has a value of 869.  I wonder if a simple explanation of this discrepancy may be that because the "bad" instance was not taking full advantage of entry cache, this caused the wait?


                BTW, I hope I am not straying too far from the original questions.  I am thinking this all ties together and thus trying to gain an understanding of some of these attributes that don't seem to be documented in great detail - or at the very least trying to find someone to point me to the detailed documentation.


                Thanks!  I do greatly appreciate the mental stimulation that comes from these types of discussions!