knitti wrote:
On 12/12/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote:
knitti wrote:
The problem would be to "forget" calling ap_bclose() after ending a
connection, either because all data has been sent or the connection has
been aborted. What I can read with some confidence, is that keeping a
socket open beyond sending any data is not intentional, and there is
nothing (for me) which suggests that it would happen at all.
Logically if that was the case, wouldn't you think you would run out of
sockets in just a few minutes after starting httpd? I am not saying
there isn't any bugs in httpd, or that there is. Fair to assume there is
some, but to that extend, I couldn't imagine so. Just think about it for
a second. What the effect of it would be if that was the case?
I think you misunderstood me. I meant I don't see any obvious occasion
in which the problem I assumed (forgetting ap_bclose() ) would occur.
So I don't see any bug (surpise), but something occurs. So either I don't
see the bug because its not obvious (surprise, again), or my
assumption (ap_bclose() not called) is wrong.
My question: would not calling ap_bclose() show this behaviour ?
May be, I am not sure, but based on your previous information provided
it would make sense I guess. A stupid idea, may be something like Ajax
might keep it going... No, I don't think so.
- Application needs sockets and send request to create and destroy them
and keep using them after they are created. Who does that, kernel or
application?
I assume the kernel creates the actual socket, but the app keeps it as long
as it wants (or longer ;-)
- Who receive the sockets creation and destroy requests and will create
them or destroy them and pass the handle to the application when ready.
The Kernel, or the applications?
- Who is handling the signaling, meaning handshake, opening, close_wait,
retransmitions, etc. Application or kernel?
- So, in the end, if a socket is in close_wait, is it the application,
or the kernel at that point? Meaning, was it already requested to be
close and is now a signaling issue, or an application that hasn't asked
to close the socket yet? (;>
I *assume* that it is the application forgetting to close(), because if the
kernel "forgets" to close() something what is more or less a file, we would
also have massive stale open files being around.
Make sense.
- If jam in close_wait state, is it because it hasn't send the ACK on
the request from the client to close the socket?
- Or is it that it did send the ACK to the client and is now waiting on
the final ACK from that client to do it?
- Or is it that it reach that point because it was an none fully open
three way handshake establish connection to start with may be?
- Or it is because the client just open a socket, get what it needed and
didn't bother to do the proper closing of the sockets as it should be?
_please_, read my last mails, or look at a TCP state diagram.
I did, thank you.
- Now, where is the application, in the case httpd involved here?
CLOSE_WAIT is a defined state. The most simple explaination is not
closing the socket even after recognizing there is nothing more to
read from it.
One would think so. What would really be nice is to be able to create
these states I guess to understand how they are staying there in the
first place. I try to see if I could, but I can't right now.
- Where can keep alive in httpd help, or not?
- Where pf proxy help or not?
- Where keep alive in tcp stack (sysctl) help or not?
these three questions I simply don't understand. Please rephrase.
It was intended as a reflexion more then questions to show where each
part could affect the efficiency of httpd, but in this case, we left the
part related to it and just focus in why CLOSE_WAIT was present.
However, there must be a relation as the original posted corrected his
problem of having to many CLOSE_WAIT state by reducing the KEEP_ALIVE to
10 seconds, instead of the wrong setup of 150 seconds. However thinking
about it, unless the wrong informations was provided, there shouldn't
have been a CLOSE_WAIT issue, but a lack of available sockets. I think
they should have been FIN_WAIT_2 and not CLOSE_WAIT if I think about it.
I must have mix the two then assuming it was FIN_WAIT_2, but continue
with CLOSE_WAIT. I think you can definitely help FIN_WAIT_2, but as for
CLOSE_WAIT as you put it and as I think more about it, you are right.
Would looks like an application issue somehow.
That's why there isn't a single answer to the questions here and it will
always depend on your specific setup, traffic patterns and load, etc.
I seems we are here of different opinions. I'm more or less convinced
now, that there is a bug not closing the socket even after httpd has
nothing more to send. Under the assumption my interpretation of the
problem is not fundamentally flawed.
May be not of a different opinion. There obviously was a part that I
miss understood and ready more on it corrected my understanding. So, if
you haven't fix the bug in httpd, if there is one. You fix the bug in me
however. (;>
Example, you could reduce the keep alive in sysctl a lots if you want to
help the close_wait, but at the same time this will increase all the
exchange messages between valid connections as well. So, on one hand to
will affect the delay in closing your sockets sooner, but at the same
time you will increase the load on other already active connections.
well, I think turnig the wrong knobs will do harm, there you are right.
tuning TCP keep alives would be the wrong knob
Not in all cases, but for this particular one here yes it would be.
left, unless it does give you a problem, other then a feeling of wanting
it to look different, you should put it to rest I think.
unless I can reproduce it, I will also let it rest after being convinced
of not finding the bug by reading the code alone ;)
Good luck in your research.
Daniel
