I'm hoping this will be an easy question! I'm reviewing OCI and trying to determine if I can see the actual number of cache hits, not just the cach hit ratio. I don't see a column that I can add to my performance views - but maybe it's listed as something else and I'm overlooking it? I don't see it as part of the client, nor do I see it in the data warehouse. Does it exist?
I would like to get a better understanding of the ratio being reported, but I would also like to see the raw number of cache hits before it is calculated as a ratio.
Thank you in advance!
I apologize for the delayed response to your question.
OnCommand Insight only reports the volume cache hit ratio details, not the actual number of cache hits. Insight will break out the cache ratios for both reads and writes. I believe the cache hit ratio is a metric we are getting directly from the array as opposed to calculating it behind the scenes; hence, why we don't have the actual number of cache hits.
Hope this helps.
Thanks, Joe! This is good to know - I wasn't sure if I was overlooking it. So, if I wanted to see the actual number of cache hits, would I need to pull a report directly from the array?
What version of ONTAP? I can make an internal inquiry and see if there is a report/command you can run.
In terms of OnCommand Insight documentation, thank you for your feedback on this front. Please note that the Installation and Administration Guides outline what commands we run for each vendor specific data source. In the client we also provide a help menu that will explain what you are seeing. I captured this additional detail from the help menu which might help.
You can also leverage the table customization view to validate what metrics are available. Several of the performance metrics are not viewable by default in the client until you select to view them via the customization options.
We are running ONTAP 8.0.1 7-Mode.
I've been spending a lot of time reading the manuals, reviewing some documentation in Knowledgebase, and such, trying to get a handle on the performance reports. I've a pretty good understanding of the capacity and inventory reports and I can easily reconcile what I see in OCI against the DWH report.
But the performance bit is taking some time to understand. I've seen the cache ratio definitions in the Performance user manual, and there is also a definition for these in the DWH manual. Granted, I'm new to DWH and BI reporting, but I don't think it should be this hard to get! If there are any other resources you might be able to suggest for NetApp OCI or DWH performance reporting, I would be grateful.
I may be back with more questions as I work through it.
Thank you again for putting up with my questions!
You are saying above "This column is empty for storage arrays that do not collect cache hit information". On some specific arrays we do get the node information such as iops and throughput, however we do not get cache hit ratios. Can you tell why would an array not collect this information? Thank you, Mark
The metrics captured are dictated by the data source being leveraged and the array technology in question. For arrays where cache hit ratio metrics are not captured, I am not sure if this is because the array vendor does not publish that data and/or is not available via the data source OCI uses versus OCI engineering has not enhanced the data source in question to collect the cache hit ratio metric. If there is a specific array model you need these metrics, but they are not being capture, I recommend escalating to find out why it is not supported. The support matrix (when updated) should outline what metrics are supported per array.
Here's the command to examine in-depth cache performance metrics from the CLI:
stats show -p flexscale-access
To my knowledge, that's the fully monty. (Access to that command may be specific to our gear and our licensing setup, and may not apply elsewhere, mind you..)
That command will provide a realtime view of cache statistics in terms of usage %, the actual number of cache hits and misses per second, as well as a quantitative view of replaced reads, which is nice. Allowed to run, it will dump a new row of stats every few seconds.