iMonitor cache statistics are incorrect if hit count exceeds 4GB

  • 7023494
  • 01-Nov-2018
  • 19-Nov-2018

Environment

eDirectory 9.x

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

Reported to engineering.

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.