topic Re: STATE in 'top' command in Operating System - HP-UX

STATE in 'top' command

Fred Martin_1 — Wed, 08 May 2002 17:57:02 GMT

Where can I find a defenition for the various states displayed by the 'top' command?

I'm wondering about the difference between sleep, wait and run.

If the 10 top entires are all sleep, for example, is that telling me something about system performance?

Re: STATE in 'top' command

Pete Randall — Wed, 08 May 2002 18:07:54 GMT

Fred,

The various states are sleeping, waiting, running, starting, zombie, and stopped, with sleeping and running being the most common. Because only one process can be running on a given cpu at any given moment, the scheduler puts the other process in a sleep state - this is why you see so many sleeping.

HTH,
Pete

Re: STATE in 'top' command

Mladen Despic — Wed, 08 May 2002 18:18:44 GMT

From /usr/share/doc/proc_mgt.txt :

Process States and transitions
===============================

Through the course of its lifetime, a process transits through several
states. Queues in main memory keep track of the process by its process
ID. A process resides on a queue according to its state; process states are
defined in the proc.h header file. Events such as receipt of a signal cause
the process to transit from one state to another.

Table 1-3 Process states
State, followed by What Takes Place

idle (SIDL):
Process is created by a call to fork, vfork, or exec; can be scheduled
to run.

run (SRUN):
Process is on a run queue, available to execute in either kernel
or user mode.

stopped (SSTOP):
Executing process is stopped by a signal or parent process:

sleep (SSLEEP):
Process is not executing; may be waiting for resources:

zombie (SZOMB):
Having exited, the process no longer exists, but leaves behind for
the parent process some record of its execution.

When a program starts up a process, the kernel allocates a structure for
it from the process table. The process is now in idle state, waiting for
system resources. Once it acquires the resource, the process is linked
onto a run queue and made runnable. When the process acquires a
time-slice, it runs, switching as necessary between kernel mode and user
mode. If a running process receives a SIGSTOP signal (as with control-Z
in vi) or is being traced, it enters a stop state. On receiving a SIGCONT
signal, the process returns to a run queue (in-core, runnable). If a
running process must wait for a resource (such as a semaphore or
completion of I/O), the process goes on a sleep queue (sleep state) until
getting the resource, at which time the process wakes up and is put on a
run queue (in-core, runnable). A sleeping process might also be swapped
out, in which case, when it receives its resource (or wakeup signal) the
process might be made runnable, but remain swapped out. The process
is swapped in and is put on a run queue. Once a process ends, it exits
into a zombie state

Re: STATE in 'top' command

Ricardo Bassoi — Wed, 08 May 2002 18:21:17 GMT

Hi,

The easy way is to do a 'man'

man top

and you will have all the information that you need.
Regarding the states I agree with Pete.

Regards

Re: STATE in 'top' command

Fred Martin_1 — Wed, 08 May 2002 18:23:34 GMT

I heard someplace that 'wait' was a bad thing, that it meant the process was waiting on hardware, i.e. a process that can read a disk faster than the disk can deliver the data.

Is that true?

Re: STATE in 'top' command

Fred Martin_1 — Wed, 08 May 2002 18:28:19 GMT

Ricardo, sorry I did the 'man' and it names the states but doesn't define them. The info above answeres my questions, though.

Re: STATE in 'top' command

Mladen Despic — Wed, 08 May 2002 18:42:54 GMT

Fred,

Sometimes processes will wait for resources by design.
For example, if you run 'hpterm' the process will "sleep" beacuse it is waiting for the terminal input.

In other cases, it is a question of performance tuning, but I don't think you can eliminate processes waiting for other resources.

There are different types of wait states. If you have Glance, you can check definitions of the following metrics in /opt/perf/paperdocs/gp/C/metrics.txt :

PROC_CACHE_WAIT_PCT
PROC_CDFS_WAIT_PCT
PROC_DISK_SUBSYSTEM_WAIT_PCT
PROC_DISK_WAIT_PCT
PROC_GRAPHICS_WAIT_PCT
PROC_INODE_WAIT_PCT
PROC_IPC_SUBSYSTEM_WAIT_PCT
PROC_IPC_WAIT_PCT
PROC_JOBCTL_WAIT_PCT
PROC_LAN_WAIT_PCT
PROC_MEM_WAIT_PCT
PROC_MSG_WAIT_PCT
PROC_NFS_WAIT_PCT
PROC_OTHER_IO_WAIT_PCT
PROC_OTHER_WAIT_PCT
PROC_PIPE_WAIT_PCT
PROC_PRI_WAIT_PCT
PROC_RPC_WAIT_PCT
PROC_SEM_WAIT_PCT
PROC_SLEEP_WAIT_PCT
PROC_SOCKET_WAIT_PCT
PROC_STREAM_WAIT_PCT
PROC_SYS_WAIT_PCT
PROC_TERM_IO_WAIT_PC