Re: Runaway listener processes on Ora7.3.4, Digital UNIX 4.0D

I've seen similar problems on other unix systems: typically occurs when a user drops their end of the connection less than "gracefully" (i.e. running MSWindows-whatever, the click the [X] in the top right hand corner of their session instead exiting the application). Often the background process on the server will have a parent pid of 1 (init). They'll never get notification from the foreground process that its time to cleanup and say goodnight. On BSD flavors of unix (which I believe Digital Unix is), I have seen the runaway CPU consumption, but not the RAM ... different strokes. You may need to develop and algorithm for identifing the beasts and reducing their numbers (ie using kill -11 or kill -15 to give them a chance to exit gracefully). It really gets to be fun when they become zomies (or <defunct>). Your mileage may vary. -caveat-caveat-caveat-

jc

In article <8u5pfh$s9f$1_at_Mercury.ev.co.yu>,   "Vukadinov Branislav" <Branislav.Vukadinov_at_ev.co.yu> wrote:
> Hi, all
>
> I'm working in Oracle 7.3.4 on Digital Unix 4.0.d. Hardware is
 AlphaServer
> 4100, 1 CPU 400 MHz, 512 MB RAM, 2 GB swap.
>
> In a last few days we have a problem with the machine.
>
> The main database processes are fine, but we have a lot of spawned
 processes
> from the listener, "oracleedns" ("edns" is the name of the instance).
 Some
> of those processes are choking our machine. Output of "ps aux" shows
 them to
> be in a "R"unnable state and sucking CPU and RAM. Those processes keep
> multiplying until we get "out of swapspace" message and machine
 stalls. The
> only solution is to reboot.
>
> AFAIK, for every client connection, listener spawns one process
 "oracleedns"
> to handle the request. Most of those processes run fine, but some of
 them go
> "hay-wire". We cannot pinpoint the problem, different users,
 different parts
> of application run into this. And not all of them.
>
> Those runaway processes leave large user-dump tracefiles ~100 MB, as
 oposed
> to ~10 kB for usual dumps. Naturally, it clogs up the disk.
>
> Could someone sugest how to audit this problem and find a solution?
>
> TYIA,
> Bane.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Sun Nov 12 2000 - 08:09:57 CET