Environment
Situation
In iMonitor database cache statistics, the number of hits is supposed to be the sum of the block and entry hits. However the “largest” number it can show is around 4,294,967,296 (2^32) so every time one of these counters gets to that number it “rolls over” back to zero.
If it’s the “hit” counter that rolls (most probably as it’s the one growing fastest), suddenly there are a lot more “Faults” than “Hits” and the calculated % is wrong (incorrectly shows terrible cache hit rate efficiency).
Resolution
As a workaround, clear statistics and monitor afresh; it will take some time to reach the 4,294,967,296 limit or retrieve the values using an LDAP browser from the cn=Monitor object and perform a manual calculation.
Cause
Additional Information
Using LDAP cn=monitor data, we can see that the values in eDirectory are valid and not rolled at the 4,294,967,296 boundary (32-bit integer); this is just an issue with iMonitors handling of the data.
cn=Hits,cn=CacheStatistics,cn=RecordManager,cn=Monitor
cn=CacheFaults,cn=CacheStatistics,cn=RecordManager,cn=Monitor
As a workaround, clear statistics and monitor afresh, it will take some time to reach the 4,294,967,296 limit or retrieve the values using an LDAP browser and perform a manual calculation.