RE: defunct processes after patch application on Compaq Tru64 Uni

Vivek - I agree with Stephane about the processes. The patch you applied, was it to Tru64 or the database? Offhand, it sounds like the O.S. isn't cleaning up after itself. This problem might have nothing to do with Oracle.

Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Monday, May 26, 2003 2:52 PM
To: Multiple recipients of list ORACLE-L Unix

VIVEK_SHARMA wrote:
>
> After Applying patch Kit "4" of Compaq Tru64 Unix 5.1A , about 200
concurrent defunct PIDs are spawning during a peak concurrent user load of 800 concurrent application users .
>
> "defunct" process is generated :-
> 1) when doing an ordinary telnet unix login to the machine
>
> 2) when doing sqlplus <user>/passwd@<connect string> to the database
server
> NOTE - NO defunct process is generated when doing direct sqlplus call to
database
>
> 3) when doing application login which spawns a database connecttion thru
SQL*Net
> NOTE - The defunct PID Values belonging to a unix user keep Changing .
Seemingly NEW defunct processes keep getting spawned as old ones die off
>
> This is causing a severe Application performance degradation on production
even though there is plenty of FREE CPU & memory available
>
> NOTE -
> 1) Before application of patch kit "4" , FEWER defunct processes ( 50 at
max. ) used to exist
> at any point in time
>
> 2) Each application user spawns approx 4 unix processes while working with
the application
>
> 3) Network thruput is OK between Application & Database Server
>
> Qs. Is spawning of defunct processes during unix login normal ?
> Qs. anybody has applied Patch kit "4" on Tru64 Unix ?
> Qs. Any ideas how this issue may be approached ?
>
> Thanks
>

Vivek,

   I have no direct experience of this patch but technically a defunct (zombie) process is a process the parent process of which has died unexpectedly. Normally, when a process begets another process, it is expected to wait for a SIGCHLD signal when the child process exits. If it crashes before the child process finishes, the child process cannot die properly and continues to haunt the living. Since your problem is with SQL*Net connections, the answer to your problem is probably to be searched in the direction of tnslsnr, which normally forks the shadow processes. The listener log may provide clues. And a possible workaround (I would certainly try it) could be MTS.  

HTH, Stephane Faroult
Oriole Software

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephane Faroult
  INET: sfaroult_at_oriole.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).