Question
SLB distributes loads to multiple backend servers. If the client page view is 0, it finds that there are large connections in the TIME_WAIT status. Log on to the backend server and run the following command to confirm that the number of connections is too large in TIME_WAIT status.
while true;do netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a,S[a]}';sleep 1;done | grep TIME_WAIT
The following command output is returned.
TIME_WAIT 424
TIME_WAIT 430
TIME_WAIT 437
TIME_WAIT 447
TIME_WAIT 455
TIME_WAIT 464
TIME_WAIT 473
TIME_WAIT 481
TIME_WAIT 490
TIME_WAIT 498
TIME_WAIT 506
TIME_WAIT 513
Answer
In this case, there are two ways to solve the problem:
Note: This problem generally occurs in the layer -7 (HTTP) forwarding mode of SLB. When SLB forwards an HTTP request, the request is made of the application layer protocol. Therefore, when you modify the timeout time of the Web application, if the SLB health check parameters, such as the frequency and the net.ipv4.tcp_keepalive_time of the system, the decrease in the number of connections in the TIME_WAIT status is not significantly affected.
-
- We recommend that you use SLB layer -4 (TCP) forwarding mode. For more information, see add TCP listener. This pattern in each health check, SLB will take the initiative to send RST state of the data packet to disconnect from the server health check established TCP connection, so is not to view from SLB health check connections
- In addition to changing the TCP forwarding mode, you can also disable the health check function in the HTTP forwarding mode and reduce the number of connections in the TIME_WAIT status. However, after you disable the health check, you cannot monitor the backend servers for exceptions. If SLB forwards requests to the backend servers that are in the abnormal state, the backend servers that are in the abnormal state cannot be monitored. For more information about how to disable health check, see disable health check.
Application scope
- SLB