I'm using snmp to monitor my cisco router's cpu loading, but the number has a large difference with show proc cpu history's output. When sh tells me cpu loading is 7x%, the snmp only gets 2x%. Which number's accuracy is higher than another one?
Add a comment
|
3 Answers
The differences will be due to different ways of averaging and also the different sample period.
Some background (I wrote the command):
The intention was that this command was to be used to look for patterns in CPU utilisation, aiding the correlation of transient issues with CPU spikes (specifically call control errors with CPU spikes and call rate on the as5800 series).
"show proc cpu history" is graphing the 5 second CPU value as obtained from the "core" of IOS.
For the last 60 seconds this is accurate, bearing in mind that the values only update every 5 seconds. It will be quite spiky and unpredictable due to the run to completion nature of IOS.
After every 60 seconds an average is calculated from the collected data and stored as a data point in the 60 minute graph.
After 60 minutes an average of the hour graph is calculated and stored in the 72hr graph.
The way that the averages are calculated mean that there are bound to be variances. However it uses very little memory or CPU overhead to maintain the data. Given that the command has to run on the smallest router and line card upwards that was more important than accuracy.
'show proc cpu history' can show one minute, one hour or 72 hours of history (http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_tech_note09186a00800a65d0.shtml#showprochistory)
The OIDs for Cisco show 5 second, 1 minute or 5 minute busy percentage intervals (http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a94.shtml#topic1).
The difference could be the interval duration being used.
To a large extent, it doesn't really matter all that much. One gives you one number, and one gives you a another number nearby. Use the SNMP one to graph and collect with, and don't worry too much about the 'actual real guaranteed usage'. This is most likely due to different sampling intervals, and the impossibility of actually getting a instantaneous rate (i.e, in any particular time slice, the CPU is either 100% or 0%).
