How can I find total CPU usage in percentage? e.g. if my system has 8 CPUs and I want to list total usage for all of them, is it possible through a command?
I have tried some of the commands like top, mpstat, sar. The output of those commands has to be manipulated to derive the percentage CPU utilization. I am looking for some other command.
You might find that a bit of a setback, but Unix is a general-purpose operating system and not specifically designed to meet your personal needs. The Bell Labs. people, in short-sighted ignorance, only implemented the tools you need to build what you want and did not bother at all to anticipate what especially you might want a few decades later.
With this in mind: write a small script which converts the data you get from the system into the form you want and be done. Its the way things are.
This output is broken. The last four numbers should sum to 100.
Can you please clarify what you are exactly looking for beyond "total percentage CPU usage" ?
In most versions of "vmstat" the first line of statistics are garbage and can be discarded. On most version the output from "vmstat" with no parameters is meaningless.
All of the basic statistics commands like "sar" "mpstat" and "vmstat" take parameters from the command line for the sample period.
For example to take samples every 10 seconds for one minute:
sar 10 6
sar 10 6 | grep "Average" # Just show the average line
Many sites set up the "sadc" suite of statistics data collection crons to record statistics for the machine on an hour-by hour basis. This enables the full use of "sar" to provide historical analysis data which you can manipulate as you see fit. Use of trend data is much more useful in server monitoring than trying to do a spot check after there is a problem.
Really depends on what you are trying to achieve and how you will be presenting the information and the time periods involved.
That would be a bug. All vmstat implementations I'm aware of (Unix derivatives, BSD, Gnu/Linux) document the first line to show average values since last reboot.
I much prefer a properly set up "sar" system even thought the statistics files use disc space. I usually keep 3-months worth of raw data for rolling trend analysis.
Example of "vmstat" from a HP-UX development system: Note that the first line is garbage. The scripts which I have ported over many years ignore the first line of any "vmstat" or "iostat" output. This is not a new issue at all.
vmstat
procs memory page
faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
1 0 0 522676 907141 10 2 0 0 0 0 0 1168 5757 663 31 79 4231861895168
vmstat 10 6
procs memory page
faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
1 0 0 518736 907250 10 2 0 0 0 0 0 1168 5757 663 31 79 4232048017408
1 0 0 515225 907224 0 0 0 0 0 0 0 976 9249 668 0 0 100
1 0 0 520765 907224 0 0 0 0 0 0 0 984 1979 659 0 0 100
1 0 0 520373 907224 0 0 0 0 0 0 0 986 4095 826 0 0 100
1 0 0 523508 907224 6 0 0 0 0 0 0 1022 1590 762 0 0 100
1 0 0 522832 907172 0 0 0 0 0 0 0 990 2188 657 0 0 100
There is indeed a well known issue with implementations where 32 bit counters are still used to store these values and then overflow when the OS hasn't been rebooted for a while. I would say that's a documentation bug as this limitation should be mentioned:
Even with that bug, I wouldn't expect all CPU values to be 0 like the OP sent though.
Just looked at a machine which booted less than a day ago.
us sy id
0 1 99
Plausible? No. When it wasn't running a backup it was running an active database.
Ignoring the field overflow issues (which were and extreme example) I've always found the first line to be garbage.
Well, HP-UX might be that buggy after all if you are sure significant CPU was used on this machine. It's close source so who knows how did their developers messed if you are true ...
On the other hand, a backup use no that much CPU cycles at it's mostly I/O. A database, if really busy should use more. Did you check with sar or similar ?
In any case, I haven't had that kind of issues with Solaris since many years.