httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Ghent <>
Subject 2.0/dexter locking wierdness?
Date Tue, 01 Feb 2000 13:37:55 GMT

I'm playing the 2.0 snapshots on a server (Sun Ultra2300, Solaris
7 with kernel patch 106541-09) here, and it does something rather nasty
when a whole slew of requests are thrown at it (using 'ab -c 1000 -u

What happens is, of the 5 non-root apache processes running, one or two
will end up sucking up all of the CPU. I did a truss on these particular
processes, and they are stuck in some kind of write() loop, where
any write() call to a network socket always errors out with EPIPE. To try
to see what led up to this condition, I truss'd one of the apache
processes from start to finish. From looking at the resulting output, 
the only abnormal thing that happens right before the process enters into
the runaway write() state is that fcntl() fails right after accept()ing a
connection with EDEADLK. From that point on, all write()s for all threads
in that apache process then loop and fail constantly with EPIPE.

I saved the truss output to a file, and it is available at:

The fun begins at line 4409. For those not familiar with truss, the
"/<number>:" that prepends each line is the thread number in the process.

This state is 100% reproduceable. I'm going to try the pthread mutex
locking model next and see if the same thing happens there.


Dale Ghent
"An event e's being F realizes e's being G just in case (i) e is F,
(ii) e is G, (iii) for all e it is (physically) necessary that if e
is F then e is G, and (iv) e's being F explains e's being G. "
		- Basis of Multirealizability

View raw message