线上应用部署了两台服务器,项目发布之后跟踪线上服务器性能,发现一台load为3,一台load为1,四核服务器,有一台已经快到瓶颈了,因此紧急排查下原因
1.TOP命令查看load和占用CPU比较大的进程,显示如下
shift+c排序 占用最大的也就0.7% 1命名查看每个cpu的使用情况 基本上都处于空闲状态
2.vmstat 2 5查看io情况
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 791092 154368 1781044 0 0 0 10 1 1 0 0 100 0 0
0 0 0 791076 154368 1781044 0 0 0 0 752 1420 0 0 100 0 0
0 0 0 791092 154368 1781044 0 0 0 2 729 1395 0 0 100 0 0
0 0 0 791092 154368 1781044 0 0 0 0 760 1417 1 0 99 0 0
0 0 0 791092 154368 1781044 0 0 0 4 761 1423 0 0 100 0 0
看上去也是正常的, cs 和us也在正常范围内
3.因为两台服务器的load不同,如果是因为代码的问题,应该load是相同的,用了分布式dubbo,所以怀疑是不是dubbo的负载均衡策略不对,分别在两台服务器执行了下面的
语句:
netstat -an|grep 20880|wc -l
得到的结果差不多,连接数也不是很多
4.之后又用df命令想要查看下磁盘大小 结果系统一直没有响应 ctrl+c退出之后 也没有反应 切断连接之后 重新登录服务 top看了下load又飚上去了
怀疑是不是df的进程一直在后台执行占用CPU,ps -ef|grep df 得到一下结果,一共4条 load刚好4 貌似找对方向了
5.kill -9 pid 强行杀进程,但是一点反应都没有,进程无响应,之后就找运维去定位问题,发现是某个系统服务关闭导致df命令无法执行,直接卡死
重启系统服务之后 load就回复正常了