线上应用部署了两台服务器，项目发布之后跟踪线上服务器性能，发现一台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就回复正常了