On Sun, Sep 04, 2016 at 01:50:31AM -0500, Mike Miller wrote:
> When I run htop or top I see compiz using 100% CPU, or nearly that.
> Here is an example:
> 
> $ top -b | tail -n+7 | head -6
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 24670 mbmiller  20   0 1706m 332m  12m R  100  2.1   6105:08 compiz
>   297 root      20   0     0    0    0 R   16  0.0   1817:54 md1_raid1
> 22625 root      35  15     0    0    0 D    4  0.0   0:48.54 md1_resync
>   906 messageb  20   0 1665m 1.6g  604 S    2 10.2  41:31.37 dbus-daemon
>  1636 mbmiller  20   0 73372  52m 4048 S    2  0.3 370:22.92 Xvnc4
> 
> 
> That seemed weird.  But when I look at it using ps, it always shows
> some small number like 2% CPU for compiz:
> 
> $ ps aux | gawk '$6=="RSS" || $3>1' | cut -c-107
> 
> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> root         6  8.3  0.0      0     0 ?        S     2014 95736:08 [migration/0]
> mbmiller 15582  2.7  3.5 4343684 576972 pts/3  Sl   Sep03  23:58 /usr/lib/chromium-browser/chromium-browser
> mbmiller 16733  1.5  4.2 3108676 703844 pts/3  Sl   Sep03  11:55 /usr/lib/chromium-browser/chromium-browser
> root     22625  1.7  0.0      0     0 ?        DN   00:57   0:48 [md1_resync]
> mbmiller 24670  2.0  2.0 1712416 340952 ?      Rl   Feb06 6105:17 compiz
> 
> 
> So my question is why is there that huge difference?  If I run htop
> in one xterm and ps in another at the same time, they still give
> these very divergent results.

It is worth reading the man page for ps(1) and htop(1).

ps(1) says:

      %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.

and top(1) says:

        1. %CPU  --  CPU Usage
           The task's share of the elapsed CPU time since the last screen
           update, expressed as a percentage of total CPU time.

>From ps we can also see that compiz has been running since February,
i.e. it has a very high real time. Thus cputime/realtime is low.

This suggests something bad has happened 'recently', causing compiz to
spin, when it normally just sleeps and occasionally does something.

      Andrew