On 04.01.2009 15:56, Ruediger Pluem wrote:
On 01/04/2009 03:48 PM, Rainer Jung wrote:
On 04.01.2009 15:40, Ruediger Pluem wrote:
On 01/04/2009 03:26 PM, Rainer Jung wrote:
On 04.01.2009 14:14, Ruediger Pluem wrote:
On 01/04/2009 11:24 AM, Rainer Jung wrote:
On 04.01.2009 01:51, Ruediger Pluem wrote:
On 01/04/2009 12:49 AM, Rainer Jung wrote:
On 04.01.2009 00:36, Paul Querna wrote:
Rainer Jung wrote:
During testing 2.3.1 I noticed a lot of errors of type EMFILE:
"Too
many open files". I used strace and the problem looks like this:
- The test case is using ab with HTTP keep alive, concurrency 20
and a
small file, so doing about 2000 requests per second.
What is the exact size of the file?
It is the index.html, via URL /, so size is 45 Bytes.
Can you try if you run in the same problem on 2.2.x with a file of
size 257 bytes?
I tried on the same type of system with event MPM and 2.2.11. Can't
reproduce even with content file of size 257 bytes.
Possibly you need to increase the number of threads per process with
event MPM
and the number of concurrent requests from ab.
I increased the maximum KeepAlive Requests and the KeepAlive timeout a
lot and during a longer running test I see always exactly as many open
FDs for the content file in /proc/PID/fd as I had concurrency in ab. So
it seems the FDs always get closed before handling the next request in
the connection.
After testing the patch, I'll try it again with 257 bytes on 2.2.11 with
prefork or worker.
IMHO this cannot happen with prefork on 2.2.x. So I guess it is not worth
testing.
It still confuses me that this happens on trunk as it looks like that ab does
not
do pipelining.
^The strace log shows, that the sequence really is
- new connection
- read request
- open file
- send response
- log request
repeat this triplet a lot of times (maybe as long as KeepAlive is
active) and then there are a lot of close() for the content files. Not
sure, about the exact thing that triggers the close.
So I don't necessarily see pipelining (in the sense of sending more
requests before responses return) being necessary.
I tested your patch (worker, trunk): It does not help. I then added an
error log statement directly after the requests++ and it shows this
number is always "1".
Regards,
Rainer
