| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Important: Oracle processes taking lots of CPU
First, I can't believe I spelled Dennis' last name wrong, but it was just a
character inversion I didn't see (I type fast, but my backspace frequency is
high).
I thought I suggested a possibility in the previous transmission, that being you may have found one mode of the elusive "zombie" bugs. That is, this process is spining for a file read alright, but it is the missing stdin/stdout ack/nak with the client that is missing. If you can identify the client side and it is still alive, then that is *NOT* what is happenning. So if the OS thought that other guy was dead, gone, forgotten, and reassigned the file descriptors to a new process, then the zombie might never time out because select will wake him up every time the other process does anything, and he'll sit there spinning away, probably getting repeated exception fds wakeups to your spin count (because he can't really talk to the other process any more) and either retrying himself after a sleep or getting wakened by the post someone else is doing to any one of the file descriptors. (Okay, that analysis is not tight and you'd need to code to really figure it out.)
Then again, this could be totally wrong, but we see values for both read and write fds in the same call.
This is somewhat similar to communications files in DTSS, but I never dug deep into "select". I suppose you might have read and write simultaneously in a pipeline, but why would an Oracle background process be doing that?
If someone has an explanation for non-zero contents in both the read and write descriptors and/or the wierd value (lookin' like an fds) in the timeout value, I'd love to hear it. What I'm saying is that this sure looks like a bug to me. (Ergo the cigar I awarded you methaphorically earlier.)
Regards,
mwf
-----Original Message-----
From: New DBA [mailto:new_dba_on_the_block_at_yahoo.com]
Sent: Wednesday, November 24, 2004 9:53 AM
To: mwf_at_rsiz.com; sfaroult_at_roughsea.com; Tony.Adolph_at_o2.com;
ORACLE-L_at_freelists.org
Subject: RE: Important: Oracle processes taking lots of CPU
Hi Mark,
> But I'll toss in a few bits anyway. The man page
> section on the system call
> or library reference "select" is often not loaded on
> various derivatives of
> Dennis Ricthie's operating system.
>
Man page shows the following information (extract):
NAME
select - synchronous I/O multiplexing
SYNOPSIS
#include <sys/time.h>
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set
*errorfds, struct timeval *timeout);
void FD_CLR(int fd, fd_set *fdset);
int FD_ISSET(int fd, fd_set *fdset);
void FD_SET(int fd, fd_set *fdset);
void FD_ZERO(fd_set *fdset);
DESCRIPTION
The select() function indicates which of the
specified file
descriptors is ready for reading, ready for writing, or has an error
condition pending. If the specified condition is false for all of the
specified file descriptors, select() blocks, up to the specified
timeout interval, until the specified condition is true for at least
one of the specified file descriptors.
The select() function supports regular files, terminal and pseudoterminal
devices, STREAMS-based files, FIFOs and pipes. The behaviour
of select() on file descriptors that refer to other types of file is
unspecified.
Having little OS knowledge, not sure what it means! Please let me know if you can figure out why the process is calling this function almost infinitely and what impact does it have!
Thanx
New DBA
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Nov 24 2004 - 11:35:03 CST
 |
 |