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
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
database: ldbm database
# database, monitor, ldbm database, plugins, config
dn: cn=database, cn=monitor, cn=ldbm database, cn=plugins, cn=config
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?
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!