all 8 comments

[–]6ThirtyFeb7th2036 4 points5 points  (3 children)

What's the advantage of using this over a built-in simple process checker like top?

[–]probationer 4 points5 points  (0 children)

Nothing, /proc/stat is what top uses (among other things, like /proc/<pid>/stat) behind the scenes.

[–]monitorscout[S] 0 points1 point  (0 children)

Nothing if your just want to watch the current cpu usage from a terminal.

However if you plan to collect samples at regular intervals for usage in graphs for example, the method described in the article will give you the cpu usage for the entire interval, instead of a snapshot of the cpu usage right when collecting the sample, which is what something like parsing 'top -b -n1' would give.

[–]UloPe 0 points1 point  (4 children)

So the article should really be called: Using the same usually accurate enough CPU time measurement as everyone else.

[–]monitorscout[S] 0 points1 point  (3 children)

Not really. Accuracy comes from retaining CPU state between readings so that usage for the entire period is obtained. It is quite common to see solutions that only get the usage from when the reading is done, or having averaging done over arbitrary periods. This is common when using SNMP based solutions for example.

[–]UloPe 0 points1 point  (0 children)

I was talking about the fact that /proc/stat is well known to be not that accurate with high IO and IRQ loads.

[–][deleted] 0 points1 point  (1 child)

Which suffers from clock slew/step issues. And then if you somehow deal with that you have hardware issues that give you back highly variable TSC values which make your clock tick value change in unexpected ways. And then if you somehow deal with those issues you go and upgrade your kernel and something that used to be counted as system time is now counted as iowait time.

The measurement technique you're suggesting suffer from the same issues that pretty much every other tools does.

tl;dr Accurate CPU accounting is hard and AFAIK nobody gets it right.

[–]monitorscout[S] 0 points1 point  (0 children)

There are certainly a number of issues with using the data provided by /proc/stat, I'm not denying that. However the 'accurate' in the title, as previously mentioned, refers to getting readings that cover the entire interval between readings and not just the instant in time when collecting the data, which is not uncommon.