当前位置:Gxlcms > mysql > 数据库短连接容易出现的问题

数据库短连接容易出现的问题

时间:2021-07-01 10:21:17 帮助过:39人阅读

对于MySQL来说返回的错误代码为99:perror99Cannotassignrequestedaddress(在出现这样的问题的时候,可以先ulimit-a看看哪些参数设置的过于严格)这个是程..

对于MySQL来说返回的错误代码为99:

perror 99

Cannot assign requested address (在出现这样的问题的时候,可以先ulimit -a 看看哪些参数设置的过于严格)

这个是程序端容易出现的问题,由于每次连接都在很短的时间内结束,导致很多的TIME_WAIT,以至于用光了可用的端口号,所以新的连接没办法绑定端口。

内核参数net.ipv4.ip_local_port_range 控制可用的端口数量:

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]}'

检测代码如上:

我们可以试着分析下TCP端开连接的四次握手:

232042683.png

1. 发起方更改状态为FIN_WAIT_1,关闭应用程序进程,发出一个TCP的FIN段;

2. 接收方收到FIN段,返回一个带确认序号的ACK,同时向自己对应的进程发送一个文件结束符EOF,同时更改状态为CLOSE_WAIT,发起方接到ACK后状态更改为FIN_WAIT_2;

3. 接收方关闭应用程序进程,更改状态为LAST_ACK,并向对方发出一个TCP的FIN段;

4. 发起方接到FIN后状态更改为TIME_WAIT,并发出这个FIN的ACK确认.ACK发送成功后(2MSL内)双方TCP状态变为CLOSED.

TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态的原因?

这是因为虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务.处理办法有以下两种方式:

1、增加端口号数量

2、减少TIME_WAIT连接状态

linux下:

通过调整内核参数解决,vim /etc/sysctl.conf,加入

net.ipv4.tcp_syncookies = 1 #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;

net.ipv4.tcp_tw_reuse = 1 #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1 #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。

net.ipv4.tcp_fin_timeout = 3 #修改系統默认的 TIMEOUT 时间

net.ipv4.tcp_max_tw_buckets = 10000#通过设置它,系统会将多余的TIME_WAIT删除掉,此时系统日志里可能会显示:『TCP: time wait bucket table overflow』,多数情况下不用在意这些信息。

/sbin/sysctl -p 让参数生效。

本文出自 “技术成就梦想” 博客,,请务必保留此出处

人气教程排行