Debian – the difference in CPU utilization between ‘ps aux’ and ‘ps -ef’

debianlinuxmonitoringprocessps

I use Ubuntu 12.04.1 Linux. I see a difference between %CPU and C output format of ps command for a process. It is not clearly noted in the ps man page.

Man pages says:

  CODE       HEADER  DESCRIPTION
  %cpu       %CPU    cpu utilization of the process in "##.#" format. Currently, 
                     it is the CPU time used divided by the time the 
                     process has been running (cputime/realtime ratio),
                     expressed as a percentage. It will not add up to 100%
                     unless you are lucky. (alias pcpu).
  c          C       processor utilization. Currently, this is the integer                  
                     value of the percent usage over the lifetime of the
                     process. (see %cpu).

So basically it should be the same, but it is not:

$ ps aux | head -1
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
$ ps aux | grep 32473
user     32473  151 38.4 18338028 6305416 ?    Sl   Feb21 28289:48 ZServer -server -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./log 


$ ps -ef | head -1
UID        PID  PPID  C STIME TTY          TIME CMD
$ ps -ef | grep 32473
user     32473 32472 99 Feb21 ?        19-15:29:50 ZServer -server -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./log

The top shows 2% CPU utilization in the same time. I know the 'top' shows the current CPU utilization while ps shows CPU utilization over the lifetime of the process.

I guess the lifetime definition is somewhat different for these two format options.

Best Answer

The %cpu and C columns are showing almost, but not quite, the same thing. If you look at the source for ps in ps/output.c you can see the differences between pr_c and pr_cpu

C is the integer value for %cpu as you can guess. The odd difference is that C is clamped to a maximum of 99 while %cpu is not (there's a check for it for %cpu but it just changes the format from xx.x% to xxx%).

Now, I'm not really sure why C has this clamping; it seems a little arbitrary. It's been there since procps 3.2.7 (2006) so it probably was from the era of single CPUs

Related Question