Thanks go out to Steve Walker <SWALKER_at_dsl.uk.ibm.com> and Vipin
Gokhale <VGOKHALE_at_us.oracle.com>.
Steve Walker suggested that there is a bug in ADVFS that can cause
this problem to occur; we however are not using ADVFS.
Vipin Gokhale says to do the following:
dbx -k /vmunix /dev/mem
(dbx) set $pid=<pid of uninterruptible process)
(dbx) t
This will discover where in the kernel the process is waiting.
Unfortunately, we have not had the program do this to us again (that
is why I'd delayed posting a summary), so I do not know the exact
reason why the process became uninterruptible. If it happens again, I
will follow up on this.
Thank you very much; what would I do without this list?
The original message:
Joshua Rowe writes:
>
> We've got this large multi-threaded multi-process application that
> accesses Oracle. We're running oracle 7.3.4 on digital unix 4.0d with
> the first large digital unix patchset installed.
>
> The model of the application is that one process waits for requests
> (the dispatcher) and dispatches the requests to the other processes
> (backends). The backends do queries and updates to the oracle
> database.
>
> Now we _use_ a large part of the operation system. Between threads,
> shared memory, fifo's, sockets, fcntl-based locking, you name it we
> use it.
>
> After a while running large queries, each of the backends become
> uninterruptible (reported by ps as being in state 'U').
>
> These problems only started happening as far as I know when we
> upgraded to Oracle 7.3.4 from Oracle 7.3.2. We did not recompile the
> application.
>
> Any clues? Thanks in advance.
jmr
--
jmr - http://meta.eksystems.com/~rowe
Just because you're paranoid doesn't mean they're not after you.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS dpu s: a--- C++++$ ULOU++++$ P+ L++++$ E+++$ W++ !N- !o>+ ?K
w---(++) O+ M-- V+++$ PS+ PE Y PGP- t+ 5 X+++ R>+ !tv b+++ DI++ D- G e
h++ r y
------END GEEK CODE BLOCK------
Received on Fri Jun 19 1998 - 18:16:25 NZST