Top command. Could someone explain the results?

Abomination · Nov 18, 2009

I do not understand these results. A php process lasted for 190ms, but is consuming 44.6% of 'what' cpu?

Code:

[removed]$ top
Tasks:   3 total,   2 running,   1 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us, 11.6%sy, 30.2%ni, 53.5%id,  4.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  2.3%us,  7.0%sy, 39.5%ni, 51.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us, 14.0%sy,  0.0%ni, 86.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  7.0%sy, 20.9%ni, 72.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  9.3%sy, 58.1%ni, 32.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  4.7%us, 18.6%sy,  2.3%ni, 74.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us, 16.3%sy, 14.0%ni, 65.1%id,  2.3%wa,  0.0%hi,  2.3%si,  0.0%st
Cpu7  :  0.0%us, 11.6%sy, 53.5%ni, 30.2%id,  2.3%wa,  0.0%hi,  2.3%si,  0.0%st
Mem:   8231256k total,  7583420k used,   647836k free,   344804k buffers
Swap:  6289408k total,    85344k used,  6204064k free,  5948092k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31249 removed  35  15 31788  14m 6912 R 44.6  0.2   0:00.19 php
10554 removed  39  19  2468 1300 1080 S  0.0  0.0   0:00.00 bash
10688 removed  39  19  2208  972  812 R  0.0  0.0   0:02.20 top

What are the terms: us, sy, ni, id, wa, hi, si, st?

I'm an idiot when it comes to these things but after experimenting for a long time really do believe that the 44.6% number is real. This is on a shared server and believe I'm consuming 44.6% of the entire dual quad core at that moment in time.

I look forward to input

David · Nov 18, 2009

Any command you're unfamilar with usually has a manual with it from ssh type

man top

and it should spit one back to you

Abomination · Nov 18, 2009

It indeed did present a manual that scrolled page by page that I cannot comprehend. I tried copying that into a document (copy paste) then using a search, but I can only seem to copy/paste 1 page at a time.

I suppose I could pipe the output into a file then somehow download it but I'm not sure what that would do if I am unable to comprehend the information.

Perhaps I can ask over at vb.com. I really wish I could search vb.com for 3 letter items but cannot (top).

David · Nov 18, 2009

Sorry I couldn't help more earlier, but it should all be in the manual under the second section for fields/columns to explain what everything means.

2. FIELDS / Columns
2a. DESCRIPTIONS of Fields
Listed below are top's available fields. They are always associated
with the letter shown, regardless of the position you may have estab-
lished for them with the 'o' (Order fields) interactive command.

Any field is selectable as the sort field, and you control whether they
are sorted high-to-low or low-to-high. For additional information on
sort provisions see topic 3c. TASK Area Commands.

a: PID -- Process Id
The task's unique process ID, which periodically wraps, though never
restarting at zero.

b: PPID -- Parent Process Pid
The process ID of a task's parent.

c: RUSER -- Real User Name
The real user name of the task's owner.

d: UID -- User Id
The effective user ID of the task's owner.

e: USER -- User Name
The effective user name of the task's owner.

f: GROUP -- Group Name
The effective group name of the task's owner.

g: TTY -- Controlling Tty
The name of the controlling terminal. This is usually the device
(serial port, pty, etc.) from which the process was started, and
which it uses for input or output. However, a task need not be
associated with a terminal, in which case you'll see '?' displayed.

h: PR -- Priority
The priority of the task.

i: NI -- Nice value
The nice value of the task. A negative nice value means higher pri-
ority, whereas a positive nice value means lower priority. Zero in
this field simply means priority will not be adjusted in determining
a task's dispatchability.

j: P -- Last used CPU (SMP)
A number representing the last used processor. In a true SMP envi-
ronment this will likely change frequently since the kernel inten-
tionally uses weak affinity. Also, the very act of running top may
break this weak affinity and cause more processes to change CPUs
more often (because of the extra demand for cpu time).

k: %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. In a true SMP
environment, if 'Irix mode' is Off, top will operate in 'Solaris
mode' where a task's cpu usage will be divided by the total number
of CPUs. You toggle 'Irix/Solaris' modes with the 'I' interactive
command.

l: TIME -- CPU Time
Total CPU time the task has used since it started. When 'Cumulative
mode' is On, each process is listed with the cpu time that it and

m: TIME+ -- CPU Time, hundredths
The same as 'TIME', but reflecting more granularity through hundredths of a second.

n: %MEM -- Memory usage (RES)
A task's currently used share of available physical memory.

o: VIRT -- Virtual Image (kb)
The total amount of virtual memory used by the task. It includes all code, data and shared
libraries plus pages that have been swapped out. (Note: you can define the STATSIZE=1 environment
variable and the VIRT will be calculated from the /proc/#/state VmSize field.)

VIRT = SWAP + RES.

p: SWAP -- Swapped size (kb)
The swapped out portion of a task's total virtual memory image.

q: RES -- Resident size (kb)
The non-swapped physical memory a task has used.

RES = CODE + DATA.

r: CODE -- Code size (kb)
The amount of physical memory devoted to executable code, also known as the 'text resident set'
size or TRS.

s: DATA -- Data+Stack size (kb)
The amount of physical memory devoted to other than executable code, also known as the 'data resi-
dent set' size or DRS.

t: SHR -- Shared Mem size (kb)
The amount of shared memory used by a task. It simply reflects memory that could be potentially
shared with other processes.

u: nFLT -- Page Fault count
The number of major page faults that have occurred for a task. A page fault occurs when a process
attempts to read from or write to a virtual page that is not currently present in its address
space. A major page fault is when disk access is involved in making that page available.

v: nDRT -- Dirty Pages count
The number of pages that have been modified since they were last written to disk. Dirty pages
must be written to disk before the corresponding physical memory location can be used for some
other virtual page.

w: S -- Process Status
The status of the task which can be one of:
'D' = uninterruptible sleep
'R' = running
'S' = sleeping
'T' = traced or stopped
'Z' = zombie

Tasks shown as running should be more properly thought of as 'ready to run' -- their task_struct
is simply represented on the Linux run-queue. Even without a true SMP machine, you may see numer-
ous tasks in this state depending on top's delay interval and nice value.

x: Command -- Command line or Program name
Display the command line used to start a task or the name of the associated program. You toggle
between command line and name with 'c', which is both a command-line option and an interactive
command.
When you've chosen to display command lines, processes without a command line (like kernel
threads) will be shown with only the program name in parentheses, as in this example:
( mdrecoveryd )

Either form of display is subject to potential truncation if it's too long to fit in this field's
current width. That width depends upon other fields selected, their order and the current screen
width.

Note: The 'Command' field/column is unique, in that it is not fixed-width. When displayed, this
column will be allocated all remaining screen width (up to the maximum 512 characters) to provide
for the potential growth of program names into command lines.

y: WCHAN -- Sleeping in Function
Depending on the availability of the kernel link map ('System.map'), this field will show the name
or the address of the kernel function in which the task is currently sleeping. Running tasks will
display a dash ('-') in this column.

Note: By displaying this field, top's own working set will be increased by over 700Kb. Your only
means of reducing that overhead will be to stop and restart top.

z: Flags -- Task Flags
This column represents the task's current scheduling flags which are expressed in hexadecimal
notation and with zeros suppressed. These flags are officially documented in <linux/sched.h>.
Less formal documentation can also be found on the 'Fields select' and 'Order fields' screens.
Click to expand...

But really top can't help you much if you're trying to track down a errant or resource intensive script.

Abomination · Nov 18, 2009

Thanks David. That explains reasonably well the bottom 4 lines of the output, except it is unclear which 'mode' the Top command was in which apparently determines if it was a percentage of the entire server, 1 quad core, or 1 core of 1 cpu.

Any idea about the earlier lines?

the terms: us, sy, ni, id, wa, hi, si, st?

I'm trying to figure out how moving to a vps might affect us. Right now we have the entire servers resources for short periods of a time, as opposed to a more controlled environment with a more limited cpu resource.

David · Nov 18, 2009

Abomination said:

Thanks David. That explains reasonably well the bottom 4 lines of the output, except it is unclear which 'mode' the Top command was in which apparently determines if it was a percentage of the entire server, 1 quad core, or 1 core of 1 cpu.
Click to expand...

Most the time, these firgures reflect for the entire range and you'd have to do the math to get actual usage. Ex: WHM reports a server load of 8, but since i have an 8 core machine the load is actually 1 (I think thats how its done)
[/quote]

Any idea about the earlier lines?

the terms: us, sy, ni, id, wa, hi, si, st?

I'm trying to figure out how moving to a vps might affect us. Right now we have the entire servers resources for short periods of a time, as opposed to a more controlled environment with a more limited cpu resource.[/QUOTE]

I honestly have no clue what any of those mean.
If you're trying to track down whats causing the server load, your hosting company should be able to tell you the script thats causing it all.

Abomination · Nov 18, 2009

David McHenry said:

Most the time, these firgures reflect for the entire range and you'd have to do the math to get actual usage. Ex: WHM reports a server load of 8, but since i have an 8 core machine the load is actually 1 (I think thats how its done)
Click to expand...

Understood.

David McHenry said:

I honestly have no clue what any of those mean.
If you're trying to track down whats causing the server load, your hosting company should be able to tell you the script thats causing it all.
Click to expand...

To me, "I don't know" is a really great answer. I'll email the hosting provider and ask them now that I know it is not an entirely tsupid (sic) question.

I also asked over at vb.com because that is one of their standard requests when asking for help.

I do not want to fix the script. It is an almost bare bones vb3 installation, I am trying to ascertain what hosting may be needed. The number of people online has doubled in the last month, and the timeout is still set the same (15 minutes).

Abomination · Nov 20, 2009

Updates.

wa = waiting for IO
us = userspace
sy = system/kernel
ni = nice processs
id = idle
hi = hardware interrupts
si = software interrupts

OK, found out what is going on, this was the output from post #1:
Code:
[removed]$ top
Tasks:   3 total,   2 running,   1 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us, 11.6%sy, 30.2%ni, 53.5%id,  4.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  2.3%us,  7.0%sy, 39.5%ni, 51.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us, 14.0%sy,  0.0%ni, 86.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  7.0%sy, 20.9%ni, 72.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  9.3%sy, 58.1%ni, 32.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  4.7%us, 18.6%sy,  2.3%ni, 74.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us, 16.3%sy, 14.0%ni, 65.1%id,  2.3%wa,  0.0%hi,  2.3%si,  0.0%st
Cpu7  :  0.0%us, 11.6%sy, 53.5%ni, 30.2%id,  2.3%wa,  0.0%hi,  2.3%si,  0.0%st
Mem:   8231256k total,  7583420k used,   647836k free,   344804k buffers
Swap:  6289408k total,    85344k used,  6204064k free,  5948092k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31249 removed  35  15 31788  14m 6912 R [B]44.6[/B]  0.2   0:00.19 php
10554 removed  39  19  2468 1300 1080 S  0.0  0.0   0:00.00 bash
10688 removed  39  19  2208  972  812 R  0.0  0.0   0:02.20 top
.

====================================================================

Found what is going on. The last few lines of the above code block referring to 44.6% cpu is meaningless because there was no specified time between updates. I had the update time set to 30 seconds and was manually updating the statistics by clicking the space key.

Further testing in the Irix mode gave this result with 1 second between updates:
Code:
top - 23:41:19 up 15 days,  4:46,  3 users,  load average: 1.40, 2.04, 2.30
Tasks:   3 total,   2 running,   1 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us, 17.0%sy,  2.0%ni, 80.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  5.0%sy, 14.0%ni, 81.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  1.0%sy,  7.0%ni, 92.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  1.0%sy,  2.0%ni, 93.1%id,  4.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  2.0%sy, 28.7%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us, 19.8%sy,  5.0%ni, 75.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  2.0%us, 17.8%sy, 12.9%ni, 67.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us, 19.8%sy, 11.9%ni, 65.3%id,  3.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8231256k total,  7920792k used,   310464k free,   337244k buffers
Swap:  6289408k total,    95476k used,  6193932k free,  6237480k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
18406 .........  35  15 32848  16m 6992 R [B]18.0[/B]  0.2  [B]0:00.18[/B] php
8542 ..........  39  19  2468 1304 1080 S  0.0  0.0   0:00.03 bash
Regarding the bold numbers: (180 ms / 1000ms per update) x 100 = 18.0%
That 18% is indeed the percentage of time that the core which was executing the PHP had spent between updates. In Solaris mode it would have been 18.0/8 cores = 2.25%. That is 2.25% of the entire server, but not really a useful number as an indicator of what is really going on.

Since the time between update is determined by the person running the Top command, the %cpu might not be as important as the actual time the php code needs to run.

I'll assume the other lines (cpu0 - cpu7) are a simple snapshot in time of what those are doing and, in a way, may not be a good indicator of how well things are running either.

Log in or Sign up

Top command. Could someone explain the results?

Abomination Zealot

David Regular Member

Abomination Zealot

David Regular Member

Abomination Zealot

David Regular Member

Abomination Zealot

Abomination Zealot

Share This Page

About Us

Quick Navigation

Follow us on Twitter

Log in or Sign up

Useful Searches

Top command. Could someone explain the results?

Abomination Zealot

David Regular Member

Abomination Zealot

David Regular Member

Abomination Zealot

David Regular Member

Abomination Zealot

Abomination Zealot

Share This Page