This answer has nothing to do with modperl - sorry. I have had the same
problem
on a Sybase database with a 'normal' application.
This situation can occur due to a database (b)locks, particularly if a
transaction is
composed of more than one update, or it fires a referential trigger which
has the same
effect.
The first question is what is the lock-level. Is it at the row or at the
page - I presume
the row. If the insert causes a 'fault' such that an index page becomes full
and has to
split then the whole index page will be locked regardless of row-level
locking. If the
second part of transaction is waiting on someone else then we can get the
deadly
embrace situation. However, it can normally be cleared on time-outs. If
however
you are acquiring these blocks faster then they time out, then in very short
order
you will be .. er.. screwed.
Sometimes it can help to do dirty reads if the data you need to present does
not need to be up to date.
One of the cures for this is an update pipe. Instead of each 'program' doing
the insert
on the database they funnel the updates to a single threading process. Reads
of
course can be be done by the individual 'programs'.
Can you confirm that the connection is freed if you kill the process that is
blocked?
If so this gives you another way out.
----- Original Message -----
From: "Robert Landrum" <[EMAIL PROTECTED]>
To: "Kevin Slean" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, 03 May, 2001 03:40 PM
Subject: Re: Apache Processes hanging
> At 10:37 AM -0400 5/3/01, Kevin Slean wrote:
> >Mod_perlers,
> >
> >I have a problem with Apache and was looking for your thoughts on my
problem
> >or some additional mailing lists more focused on just Apache.
> >
> >I have 70 httpd daemons running and some of them just appear to hang. As
> >time goes by, the number of hung processes increases such that there are
no
> >working ones left to perform real work. Consequently transaction
processing
> >performance drops eventually to zero.
> >
> >Our web transactions running through these httpd daemons should not take
> >more than 60 seconds in a worst case scenario. Yet, some of these 'hung'
> >processes have been on the same transaction for over 30 hours. I
> >originally thought that this was a mod_perl problem and was buried in the
> >CGI/Perl routines performing the transactions. However, upon closer
> >inspection, I have found that these hanging processes are also running
JAVA
> >servlets and gif gets. This makes me suspect that it is an Apache
problem.
> >
> >I ran truss on the hung processes and found that they fell into two
camps.
> >The first group was sitting at a read system call. The second group was
in
> >a loop with sigalarm going off every 10 seconds.
> >
> I'm having similar problems, but we think it's directly related to
> Oracle. Basically, a connection is made to the Oracle database, a
> transaction is started and finished, but the connection to the
> database doesn't go away and the statement (at least from the oracle
> side) never seems to finish. The data is present in the database
> (these are insert statement, btw). Over time, every process collects
> one of these hanging statements and it eventually overwhelms our
> oracle database. The only solution is to restart apache every 5
> minutes to eliminate the built-up non-finished transactions.
>
> Has anyone seen this before?
>
> Rob
>
> --
> As soon as you make something foolproof, someone will create a better
fool.
>
