Transient database connection problems

For MySQL, the returned error code is 99: perror99Cannotassignrequestedaddress (when such a problem occurs, you can first ulimit-a to see which parameters are too strict). This is a process ..

For MySQL, the returned error code is 99: perror99Cannotassignrequestedaddress (when such a problem occurs, you can first ulimit-a to see which parameters are too strict). This is a process ..

For MySQL, the returned error code is 99:

Perror 99

Cannot assign requested address (when such a problem occurs, you can first ulimit-a to see which parameters are too strict)

This is an easy problem on the program end. Because each connection ends in a short period of time, a lot of TIME_WAIT is used up, so that the available port number is used up, so the new connection cannot bind the port.

The Kernel Parameter net. ipv4.ip _ local_port_range controls the number of available ports:

Sysctl-a | grep port

Net. ipv4.ip _ local_port_range = 32768 61000

Netstat-nt | awk '/^ tcp/{++ state [$ NF]} END {for (key in state) print key, "\ t ", state [key]}'

The check code is as follows:

We can try to analyze the four handshakes of TCP connection opening:

1. The initiator changes the status to FIN_WAIT_1, closes the application process, and issues a tcp fin segment;

2. when receiving the FIN segment, the receiver returns an ACK with a confirmation serial number, and sends an EOF to the corresponding process, and changes the status to CLOSE_WAIT, after receiving ACK, the initiator changes its status to FIN_WAIT_2;

3. the receiver closes the application process, changes the state to LAST_ACK, and sends a tcp fin segment to the other party;

4. After receiving the FIN, the initiator changes the status to TIME_WAIT, and sends the ACK confirmation for this FIN. After the ACK is sent successfully (within 2MSL), the TCP status of both parties changes to CLOSED.

Why does TIME_WAIT status still need to wait for 2MSL to return to the CLOSED status?

This is because both parties have agreed to close the connection, and the four handshake packets are also coordinated and sent, it can be directly returned to the CLOSED state (just like from SYN_SEND to ESTABLISH State), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you sent will be received by the other party. Therefore, the SOCKET in the LAST_ACK status of the other party may fail to receive the ACK message due to timeout, but resend the FIN message, therefore, the TIME_WAIT status is used to resend potentially lost ACK packets.

A large number of sockets in the TIME_WAIT status are even more than those in the Established status, seriously affecting the server's processing capabilities, or even exhausting available sockets and stopping services. there are two solutions:

1. Increase the number of port numbers

2. Reduce the TIME_WAIT connection status

In linux:

Solve this problem by adjusting the kernel parameters. Add vim/etc/sysctl. conf

Net. ipv4.tcp _ syncookies = 1 # indicates enabling SYN Cookies. When a SYN wait queue overflows, cookies are enabled to prevent a small number of SYN attacks. The default value is 0, indicating that the process is disabled;

Net. ipv4.tcp _ tw_reuse = 1 # indicates enabling reuse. Allow TIME-WAIT sockets to be re-used for a New TCP connection. The default value is 0, indicating that the TCP connection is disabled;

Net. ipv4.tcp _ tw_recycle = 1 # indicates to enable quick recovery of TIME-WAIT sockets in TCP connections. The default value is 0, indicating to disable it.

Net. ipv4.tcp _ fin_timeout = 3 # modify the default TIMEOUT time of the system

Net. ipv4.tcp _ max_tw_buckets = 10000 # by setting it, the system will delete the redundant TIME_WAIT. In this case, the system log may display "TCP: time wait bucket table overflow 』, in most cases, you do not need to care about this information.

/Sbin/sysctl-p to make the parameter take effect.

This article is from the "Technology Achievement dream" blog. Please keep this source