On Fri, Sep 13, 2013 at 12:40:45PM +0400, Sergey Pinchuk wrote:
Thank you. These ones just show empty connections that are closed by the
client soon after opening. In tcp mode, what normally happens is that the
close is forwarded to the other side, and when the other side closes in
turn, the connection to the client finishes as well.
So we may have various possible cases here :
- it is possible that the close happens before haproxy manages to connect
to the server and that we end up in a rare case where nothing else moves.
- for whatever reason the close is not forwarded to the server but still
the timeout is cleared. I don't think this happens thanks to your
graph that shows CLOSE_WAIT only taking a lot of room.
- maybe it's only the server that does not close in response. It could
be possible because then the connection to the server would be in
FIN_WAIT2 and vanish quickly enough not to appear in a significant
way on your graph. Still, haproxy's server timeout should trigger
in this case.
- maybe the server correctly responds and haproxy forgets to forward.
That's quite strange as well but should be studied.
It would be nice if you could check on the server side what the situation
looks like (server responds data maybe, etc...).
Hi again, sorry for this big delay. Problem is detected on production
system, where is very little space to operate. So main problem is how to
trace "buggy" session that is forwarded from frontend to backend and to
see is server responds or not. Especially if we are talking about
encrypted traffic.
