Tag Info

Hot answers tagged

6

No, this is not possible. TIME_WAIT is a state that acts like a bucket to catch packets that could belong to the closed connection and could screw up a new connection using the same IP/Port combinations. This is an error-catching state. Replaying packets from the original connection will be sent to the bit-bucket and not interfere with any other connections ...


3

TIME_WAIT exists for a reason and the reason is that TCP packets can be delayed and arrive out of order. Messing with it will cause extra broken connections when they ought to have succeeded. There's an excellent explanation of all of this here. Your problem is that you are not reusing your MySQL connections within your app but instead you are creating a ...


3

I want to reduce these TIME_WAIT connections The best solution is to find something else to occupy your time or something else you enjoy doing so that you no longer want to reduce these TIME_WAIT connections. If you still find that you have this irrational desire, therapy may be effective.


2

TCP is layer 4, HTTP layer 7. In HTTP 1.0, HTTP Keep-Alive is used at layer 7 to simulate persistent connections using Connection header. In HTTP 1.1, connections are assumed persistent by default and then rely on TCP only to do that job. Requests can be pipelined in the same TCP connection, then one side will set Connection: close in the last request or ...


2

You can use net.ipv4.tcp_fin_timeout kernel parameter: # sysctl net.ipv4.tcp_fin_timeout=15 Edit /etc/sysctl.conf, add to end net.ipv4.tcp_fin_timeout = 15 then run: # sysctl -p


1

The presence of connections in the TIME_WAIT state means that your server is the initiator of their closing phase. It prevents against accepting late segments and ensures that the other end has correctly closed the connection. It shouldn't be a problem to have a lot of them in most cases, it depends on the services that the server provides. The main issue ...


1

Are you looking at this based on reports of failure, or because the network trace looks funny? If you can get a simultaneous capture at the server and an affected client, that will tell you more. Possible reasons for seeing a 3-way handshake succeed but nothing thereafter: TCP Offload Engine is enabled and the NIC is running in Chimney mode (TOE- use ...


1

We reduced the error rate by 90% with the following redis command: CONFIG SET save "" This disables BGSAVE, which regulary stores all database changes on disk. The reason for the connect errors most likely come from a blocking fork() operation of the main redis process to start the BGSAVE process. The redis.conf says: # Redis may block too long on the ...


1

If you don't actually need NetFilter connection tracking, I'd suggest you either disable nf_conntrack altogether (by unloading it), or add a NOTRACK rule to the top of your iptables ruleset.


1

It sets properties for the socket, they are then allowed/enforced by the kernel. SO_REUSEADDR is POSIX compliant option when creating a socket. http://pubs.opengroup.org/onlinepubs/009695399/functions/setsockopt.html short answer - yes, and yes. So if you are making really slow connections to a lonely remote office on slow DSL, there may be an issue ...


1

Short answer - it is due to an app. The app creates sockets for a short time , closes them, then it immediately needs to open another socket. The sluggishness is related to the process(es) running out of sockets to use. When creating a socket there are options - SO_REUSEADDR abnd SO_REUSEPORT. They have somewhat similar functions, but I suspect in Centos ...


1

This is completely normal. Each new request your browser makes to the web server is a TCP connection which will use a new socket. After the handshake, data transfer, and graceful close, sockets will sit in TIME_WAIT until the kernel's timer expires. The TIME_WAIT timer is defined in the TCP RFC (RFC 793) as 2x the Maximum Segment Lifetime. The MSL is ...


1

Nginx only supports HTTP/1.0 between itself and back-end servers, so no HTTP keep-alive by default :( There are a lot of weird and wonderful third-party modules which may help, but so far I've only found keepalive support for memcache and redis, no HTTP


1

Ok, i have found the answer by my self. The munin plugin is running quite slowly and is hitting its own timeout value. if the conntrack table is full reading from /proc/net/ip_conntrack gets very very slow. the server seems to be responsive while the munin plugin is not.


1

FIN_WAIT (timeout for the FIN request acknowledgement) is not the same as TIME_WAIT (time to ensure that the socket is really not used anymore). And yes, with 65k ports in TIME_WAIT state, you only will be running out of TCP ports if you are using a single requester IP - as might be the case if all your clients are behind a NAT device. You also might be ...


1

Connection: keep-alive, close is not valid HTTP 1.1, as exactly one connection-token is allowed, so I'd expect this header to be ignored and keep-alive to be active nonetheless; in HTTP 1.0, the "Connection" tag means something completely different. There should be no technical difference whether the connection is "recycled" or not, and you should leave ...



Only top voted, non community-wiki answers of a minimum length are eligible