SUMMARY: Interpreting top output

From: <>
Date: Mon Dec 17 2001 - 03:59:21 EST
Original question below.

Thanks go to:

Casper Dik
Johan Hartzen
Gnanagurusamy  B
Kevin Buterbaugh
Darren Dunham

No real consensus on this one, only that most said that top cannot be
trusted one way or the other. Casper advised to check if top was compiled on
the same Solaris version as I was using it on (this seems to be ok), Johan
and Gnanagurusamy   suggested rounding errors and the fact that top only
displays 15 processes by default, Darren thinks the cause of this is a
difference in timing interval for the uptime and individual processes. Kevin
advised that because I am using Solaris 8 anyway I should be using the Sun
supported prstat instead of top. Thanks for the tip, I was not aware of
prstat's power.
Comparing the output of top with that of prstat, mpstat,ps -e -o comm,pcpu
(thanks Johan) and uptime shows that top's output is probably right.
Perhaps rounding errors are the answer after all.
Another cause might be (as occurred to me later) that netsaint runs a large
number of short-lived processes.

Oscar Goosens

Hi managers,

We are working on a project to implement netsaint. Currently we are
estimating the resources we'll need.
Below is a typical  example of output by top that I find on one of our

# top -S

load averages:  0.87,  1.10,  1.16
23 processes:  18 sleeping, 3 running, 1 stopped, 1 on cpu
CPU states: 26.2% idle, 36.4% user, 37.4% kernel,  0.0% iowait,  0.0% swap
Memory: 128M real, 67M free, 11M swap in use, 561M swap free

10650 root       1  58    0 3112K 2232K sleep   0:00  0.79% sshd
10788 root       1  50    0 2200K 1600K cpu     0:00  0.77% top
11164 netsaint   1  27    1 2272K 1784K run     7:56  0.54% netsaint
10679 goosenso   1  42    0 1808K 1320K sleep   0:00  0.26% ksh
10764 root       1  58    0 1808K 1320K sleep   0:00  0.18% ksh
    1 root       1  59    0  784K  312K sleep  86:52  0.18% init
10907 netsaint   1  27    1 1032K  856K run     0:00  0.09% sh
10906 netsaint   1  37    1 2272K 1144K sleep   0:00  0.09% netsaint
    3 root       1  60  -20    0K    0K sleep  41:09  0.05% fsflush
10908 netsaint   1  37    1 1008K  440K run     0:00  0.05% submit_check_re
 1268 root       1  58    0 3000K 1656K sleep  12:47  0.00% sshd_netsaint_l
    0 root       1  96  -20    0K    0K stop    0:17  0.00% sched
 7239 root      10  58    0 3608K 2016K sleep   0:14  0.00% syslogd
 8518 root       1 100  -20 2144K 1240K sleep   0:01  0.00% xntpd
   45 root      10  34    0 1544K 1168K sleep   0:00  0.00% syseventd

I do not understand the following:
I see CPU user time takes 36,4 % of  total CPU time.
When I add up the CPU time of individual processes, I find no more than
appr. 3 %
Now I understand these figures don't have to be equal, but the difference
seems very large.
Can anyone shed some light on this?

Platform: Netra T1 UltraSPARC-IIi 270MHz 128 Mb RAM, Solaris 8, top version

Regards, Oscar

De verzonden informatie is uitsluitend bestemd voor de geadresseerde
natuurlijke persoon of rechtspersoon en bevat mogelijk vertrouwelijke en/of
geprivilegeerde gegevens. Met uitzondering van de geadresseerde persoon is
het niet toegestaan de informatie openbaar te maken, te kopikren, te
verspreiden of anderszins actie te ondernemen op basis van de informatie.
Indien u de informatie abusievelijk heeft ontvangen, neem dan contact op met
de afzender en verwijder de informatie uit alle computers. Dutchtone staat
niet in voor de juiste en complete verzending van de informatie, noch is zij
aansprakelijk voor de vertraagde ontvangst hiervan.

The information transmitted is intended exclusively for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any disclosure, copying, distribution or other action  based upon
the information by persons or entities other than the intended recipient is
prohibited. If you receive this information in error, please contact the
sender and delete the material from any and all computers. Dutchtone does
not warrant a proper and complete transmission of this information, nor does
it accept liability for any delays.
sunmanagers mailing list
Received on Mon Dec 17 03:01:16 2001

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:30 EST