服务器维护中处理高并发导致的一些常见问题解决方案
这里还是按照场景来吧，毕竟场景是最能体验实用性的。首先说下服务器配置以及环境
阿里云ECS云主机，8G内存，4核的CPU，20M带宽，20G系统盘+200G数据盘，CentOS 6.5 64位，安装的一件集成lnmp环境
场景：微信发红包
这个场景是很常见的，一般客户会在整点的时候进行一次微信公众号的广告推送，这儿时候服务器的并发大概在3000到5000左右。说起来这其实并不算是高并发，但是服务器还是崩了，大概需要等待5分钟之后才能恢复正常。这有点不应该啊，分析原因。查看CPU的利用率并不高，内存使用也很正常，在阿里云控制面板里面查看网络出口流量满载，问题大概是清楚了，网络原因导致。
首先查看静态资源，发现图片大部分没有优化，于是脱下来进行无损压缩，大概省略了1M左右的大小，提交上去后依然崩溃，服务器频繁出现502。
再次检查页面的静态资源css和js，把常用的js库替换成CDN以减少请求数，提交后依然没有多少变化，502依旧。
于是查看nginx连接数，使用命令
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 结果显示
TIME_WAIT 3828 SYN_SENT 1 FIN_WAIT1 107 FIN_WAIT2 27 ESTABLISHED 661 SYN_RECV 23 CLOSING 15 LAST_ACK 284
乖乖，TIME_WAITE很高，这里务必说下TIME_WAITE的含义：TIME_WAIT：另一边已初始化一个释放。这个是啥意思呢？意思就是服务器已经主动关闭了，在等待客户端给一个回应，如果客户端一直没有回应就会出现等待，这个值就会增加。很显然，这个时候我们需要减少TIME_WAIT的值。
这里只需要修改sysctl.conf的一些参数即可，编辑/etc/sysctl.conf文件，检查
net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse=1 #让TIME_WAIT状态可以重用，这样即使TIME_WAIT占满了所有端口，也不会拒绝新的请求造成障碍 默认是0 net.ipv4.tcp_tw_recycle=1 #让TIME_WAIT尽快回收 默认0 net.ipv4.tcp_fin_timeout=30
是否是这样的设置，如果找不到对应的，在文件最后加上即可。保存后执行
/sbin/sysctl -p
配置即可生效。
20分钟后继续查看nginx连接数，结果
TIME_WAIT 87 SYN_SENT 1 FIN_WAIT1 60 FIN_WAIT2 19 ESTABLISHED 477 SYN_RECV 12 CLOSING 2 LAST_ACK 100
恢复正常，网络带宽也降下来了。
但是好景不长，第二次整点开始抢红包的时候又出现了502。查看进程发现mysqld的CPU占用率很高，导致CPU满载，服务器崩溃。修改mysql配置文件，调整max_connection为30000。其他相关参数进行了调整优化，情况有所缓解，但是短短几分钟之内CPU又满载了。
诡异！于是查看mysql中的进程，发现频繁的sql查询，而所查询的几个表数据量均在10万左右，判断是因为没有设置索引导致。咨询后端开发，果然是只设置了主键。立刻修改，提交上去五分钟后CPU降下来，稳定在10%左右，也没有出现过502了。
第二天一早，反馈说服务器很卡，查看带宽并没有占用太高。CPU也不高，但是内存却几乎耗尽。于是推测碎片太多，清理之。见帖子《Linux内存清理命令》
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
