Netstat showing 3500+ connections in TIME_WAIT

Mobile Sync Gateway
1

Following is the setup details

CB Couchbase Server 4.0.0-4051 (CE) - 1 Node
SyncGW 1.2 CE - 1 Node

Traffic running in docker container node RHEL 7.0 in 2U host having 120 GB + memory

Traffic tool in Java and syncGW are running in the same docker container presently. SyncGW IP : 10.2.1.35

When viewing netstat -anp in the syncgw container it is seen more than 3500 connections in TIME_WAIT state. Portion of it is shown below

tcp6 0 0 10.2.1.35:4985 10.2.1.35:46559 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:49763 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:46544 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:46650 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:48973 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:47230 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:49944 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:47584 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:48293 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:49541 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:49876 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:48792 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:46032 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:45212 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:47335 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:47444 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:46994 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:45941 TIME_WAIT -
tcp6 0 0 10.2.1.35:4985 10.2.1.35:45291 TIME_WAIT -

Is sync GW not managing the connections properly? Why is connections from syncgw going to timewait state or is something missed on traffic tool??.

[root@SyncGW perfreports]# netstat -anp | grep “4985” | grep “TIME_WAIT” | wc -l
3598

– Gracelin

2

@sgracelin

This seems reasonable if you are creating connections to SG in quick succession, SG is closing connections after returning a response, but TCP is holding the connection open for a period to handle delayed packets. If you wait for 5 minutes with no new connections to SG you should see the TIMW_WAIT sessions get cleaned up.

I found the following explanation on this SU thread

TIME_WAIT indicates that local endpoint (this side) has closed the connection. The connection is being kept around so that any delayed packets can be matched to the connection and handled appropriately. The connections will be removed when they time out within four minutes.