前言:

    又被阿里云的ecs主机被坑了….  一开始被那个所谓的安全组坑,后来又被 nc 端口空洞坑。。。。 这次是被阿里云默认的内核优化参数给干了….   为啥要用阿里云主机,而不用实体服务器,主要原因在于,我司是自建的机房,且可用性相当的低…   总是网络切割,谁能扛得住….. 


    事情的前后是这样,我们这里有大量的cdn注入客户端,每次上线的时候都会有大量的连接异常….  异常本身是没有关系,因为服务里都加了try catch。 但这样会造成一个很郁闷的问题,redis pop数据没到达客户端,这样造成了数据丢失… 这个是Python的异常….


该文章后续会有更新, 原文地址  http://xiaorui.cc/?p=4890


这个是 /var/log/message 内核异常日志…

通过各个环节的日志上的时间可以推断出他们的事件是关联的。执行命令 netstat -ant|grep TIME_WAIT|wc -l 统计处于 TIME_WAIT 状态的 TCP 连接数,发现处于 TIME_WAIT 状态的 TCP 连接非常多。 另外我上面有说这个参数会影响到redis数据丢失,首先redis的list模型本就没有可靠性这么一说,那也不能这么无故的丢失数据。 我通过各方面抓包分析出,client发起了pop请求,redis也收到了,也把pop的数据放到buffer里,但是返回给用户的时候失败了….

内核 sysctl.conf 参数 net.ipv4.tcp_max_tw_buckets 可以调整内核中管理 TIME_WAIT 状态的数量,当实例中处于 TIME_WAIT 及需要转换为 TIME_WAIT 状态连接数之和超过了 net.ipv4.tcp_max_tw_buckets 参数值时,/var/log/message 日志中会打印 time wait bucket table,光打印没事,内核会强制关闭超出参数值的部分 TCP 连接。

解决方法:

可以把 net.ipv4.tcp_max_tw_buckets 放大,阿里云默认值是5000,这个实在是有点少了,可以适当的调节…  该主机上有好几个高频的调度服务,本身就有大量的连接产生,后面 一大批agent连上调度服务会产生更多的连接。 这也直接导致 time wait buckets 撑满…  另外也一定要调节net.ipv4.tcp_max_syn_backlog参数…



对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!

评论已关闭。