Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: defunct processes after patch application on Compaq Tru64 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).Received on Mon May 26 2003 - 14:51:50 CDT