uninterruptible sleep

Dirk Moolman DirkM
Mon Jan 8 03:36:41 PST 2007



-----Original Message-----
From: linux-users-bounces at linux-sxs.org
[mailto:linux-users-bounces at linux-sxs.org] On Behalf Of Roger
Oberholtzer
Sent: 08 January 2007 09:19 AM


On Fri, 2007-01-05 at 18:45 +0200, Dirk Moolman wrote:
> I am trying to troubleshoot one of my linux servers that is very slow
> lately.  One thing that I worry about, is the column b
(uninterruptible
> sleep) of the vmstat output, that runs up to values of about 35.  But
I
> do not know how to troubleshoot this any further.  Searching for more
> info about uninterruptible sleep on the web, I came across this post
> (see bottom of mail).    
> 
> But from what I have learnt about this column (b), there could be many
> reason for processes being in this state.   How would I identify the
> cause of this ?

------------------------------------------
[Roger]
It is not necessarily an error. A process sleeps, for example, when it
is waiting on I/O. If a process does a blocking read call and there is
nothing to read it will block until there is something to read. The
process does nothing until there is I/O activity. It is an efficient way
to wait for something without taking system resources (CPU cycles).

Depending on how the read was done, there process can wait until more
than one character is available. The read is called uninterruptable
because the read() will not complete until the requested data is
available. However, the read can be interrupted by a signal (software
interrupt) that may do something. But when that is finished, the read()
will resume. In that sense, it is uninterruptable. Most single threaded
applications act this way. I mean single threaded in that they only do
one thing, not any system thread thing. 

To see what a process in this state is really doing, run:

	strace -p pid

where pid is the pid of the process. I bet such processes are in a
read()-like system call.


------------------------------------------
[Dirk]

I see what you mean, thanks.   To find these processes, will ps -aux be
sufficient ?    I tried this, and then ran an strace on one of these
pid's.
They all seem to belong to our Oracle database (they are probably
database processes which are handled by Oracle itself)  - this probably
means I will have to do some performance monitoring within our Oracle
system.

The processes also don't seem to hang anywhere (if I am interpreting
strace correct) - if they do, it must happen in fractions of a second,
which I won't notice, but the opsys does.

Do you think this could be normal, and just the way Oracle behaves on a
busy system ?

Dirk


Disclaimer: http://196.33.167.70/disclaimer





More information about the Linux-users mailing list