一、情况描述:
当前现场服务出现了后台服务进程在,但是前端连不上的假死情况。考虑从以下几个层面分析。
⏹数据库连接数满了;5w1h
⏹数据库锁表;
⏹线程、文件流、http请求没有正常关闭。cppu
➢查看数据库配置最大连接数:show variables like '%max_connections%'; 数值151
➢查看当前连接数show status like 'Threads%'; 数值34。
➢死锁问题排查:show OPEN TABLES where In_use > 0; 数值null
经过以上分析:数据库当前的连接数没有大于最大连接数,死锁语句查询数据为空。数据库没有问题。
三、内存问题排查
✓通过Linux系统top -c的命令查看当前后台服务使用内存约13G。系统总内存约32G。✓总使用内存数没有超过系统的80%。
✓查看后台日志没有发现内存溢出的错误或者异常。
综上所述,应不是内存导致的问题。内存问题排查可用阿里巴巴Arthas进行排查。四、线程数排查
超前位✓使用命令查询:netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
直流放大器✓发现TIME_WAIT 状态的数值为1 CLOSE_WAIT状态26349 CLOSE_WAIT状态的数值特别大。应该是未正常关闭的SOCKET连接导致。
复现
✓执行命令netstat -anp与jps 发现CLOSE_WAIT的进程号为GATE微服务对应的进程。✓使用jstack -l pid 查看closewait相关的进程。
执行netstat -anp后结果的示意图mncc
五网络问题
经询问现场ping服务器网络正常。
六总结
排查当前代码逻辑中、微服务通过socket连接的方式只有websocket。所以问题应该出现在websocket上。后询问前端同事的代码,当网络出现丢包,前端会建立大量的连接,导致后台服务卡死。后服务器又出现了假死的问题,发现数据库连接挂的较多,而连接池的数量没有设置那么大,修改代码后解决。
罗恩老师的奇迹教育