Too many sleeping processes

[Shivkumar]

Dear Sirs/Madam;

Are too many sleeping processes are undesirable ? What should be the criteria to decide ?

Thanks,
Shiv

[Jeff Schussele · Accepted solution]

Hi Shiv,

No - you only have so many CPUs so the "active" processes can *never* exceed that in theory. BUT the collection criteria of the analysis tool has a finite snapshot capability so you'll always see more non-sleeping processes than CPU count.
Don't worry about that nor the run queue length. THE most critical value of CPU "stress" is the priority queue which indicates processes that are getting bumped out of the CPU because they're not getting enough time to get their work done.

HTH,
Jeff

[Steven E. Protter]

Sleeping processes are not a real problem unless there are bottlenecks causing it.

The real thing to look for is system performance issues. Bad response time, user complaints and such.

Attaching a statistic gathering package that will help you determine if there is a real issue.

SEP

[James R. Ferguson]

Hi Shiv:

There is nothing undesirable about the state of sleep [ in computing or for that matter or the health of the human brain :-)) ].

Seriously, a process that sleeps is often a well written one. Consider a loop in which you want to periodically check for (example) the appearance of a file. In a shell you might write:

while true
do
if [ -f "myfile" ]; then
echo "yureka!"
break
fi
done

If this loop ran for awhile, it could consume needless processor cycles. In fact, a loop that is wholely compute intensive will consume 100% of a processor since it has no other interrupts such a waiting on an I/O. Such compute-intensive tight loops lead to "dynamic halts" in one parlance.

In the absence of any other interrupts to handle, one adds a call to sleep() to allow the kernel to process-switch to another stack (thread, or process).

The same loop might then look like:

while true
do
if [ -f "myfile" ]; then
echo "yureka!"
break
fi
sleep 10 # seconds
done

Thus, the state of 'sleep' and sleeping processing are not only natural but desirable.

Regards!

...JRF...

[morganelan]

Processes can be described as being in one of the following states:

* idle - Process has either just been forked; an idle process can be
scheduled to run.

* run - Process is on a run queue, available to execute in either
kernel or user mode.

* stopped - Executing process is stopped by a signal or parent
process.

* sleep - Process is not executing, while on a sleep queue (for
example, awaiting I/O to complete).

* zombie - 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.

[Indira Aramandla]

Hi Shiv,

Are too many sleeping processes are undesirable ? ---- NO

A process is described as waiting (also referred to as blocking) when it is set inactive until a specific event occurs, such as a semaphore being released or a message arriving in its message queue. In multitasking systems, such processes are expected to notify the scheduler with a system call that it is to wait, so that they can be removed from the active scheduling queue until the event occurs. A process that continues to run while waiting (i.e., continuously polling for the event in a tight loop) is said to be busy-waiting, which is undesireable as it wastes clock cycles which could be used for other process

A special case of waiting is sleeping, which is when a process is set inactive for a given period of time (i.e., 20 milliseconds). This is usually handled separately for ordinary waiting, primarily for efficiency reasons; since the clock interrupt is frequent, and keeping track of individual ticks is infeasible, the usual approach to use a system of relative counters to mark when a given process will be awakened.

Commonly used data structure for tracking sleeping processes is the delta queue, and ordered list of sleeping processes in which each process has a counter which is offset relative to last process in the list before it.

For example, if process A is sleeping for 3 ticks, process B for 5 ticks, and process C for 5 ticks, and process D for 8 ticks, then the list would be

{{ A, 3} -> {B, 2} -> [C, 0} -> {D,3}

At each clock tick, the counter for the topmost process is decremented, like so:
{A, 2} -> {B, 2} -> {C, 0} -> {D, 3}

If at this point process E is added which is to wait 6 ticks, then it would be inserted before D, and both E and D would be updated appropriately:
{A, 2} -> {B, 2} -> {C, 0} -> {E, 2} -> {D, 1}

If the topmost process reaches zero, then it (and any processes immediately following it that are also zero) is placed back into the active scheduling queue. Thus, after 2 more ticks, A is set as active; 2 ticks after that, both B and C are set as active; and so on. This approach has the advantage of minimizing the number of changes required in a given clock tick.


IA

[Mahesh Kumar Malik]

Hi Shiv

Sleeping processes are the one waiting for memory to get free. Following link may be of help

http://docs.hp.com/en/5965-4642/ch01s04.html

Regards
Mahesh

[Borislav Perkov]

Hi Shiv,

Don't worry about sleepeng processes, they are just waiting for the free memory to run. Only thing which is not good with proccesses is when they do not have enought time to finished their jobs when something don't let them doing it, like memory or cpu bottleneck.

Regards,
Borislav