服务器CPU负载太高问题查询记录

这是一个未解的疑问

---

周四晚上，有一台服务器遇到一个很怪异的现象：有流量访问时，CPU负载升到100%，可是内存使用量不大，经过NGINX切流，不接受HTTP请求，服务器又自动恢复了，本来打算准时游泳的脚步，就被问题缠住了=-=

因而咱们就开始登录有问题的服务器，经过日志和监控查看具体问题。在这切流先后，ActiveMQ消息服务和DUBBO的RPC调用，都是处于运行中的，区别在于，切流前的CPU负载忽然升高到100%，可是内存使用量只是升高，没到OOM的地步（因此没有dump文件）。

开始查看服务器：

1：经过top服务器，定位到PID为30284的jvm进程占用CPU到达100%

2：显示线程列表，按照CPU占用高的线程排序

[admin@xxxxx]# top -Hp 30284

3：找到最耗时线程的PID，而后将它转成16进制的格式

[admin@xxxxx]# printf "%x\n" 31448 77e0

4：经过jstack命令查看jvm，grep耗时线程的详细堆栈信息

[admin@xxxx] # jstack 30284 | grep 77e0 -A 60

---

进一步分析

堆栈信息比较多的是MQ线程处于TIME_WAIT状态，等待消息出队，经过观察源码，发现这里一直在计算，不过MQClient一直在要等待消息处理，因此这个状态好像也没啥问题=-=

经过查看业务日志，发现消息消费onMessage特别耗时

有些消息处理已经超过100000ms，根本算不上正常(ಥ_ಥ)，对比与其它几台服务器，一样的应用，但消息处理速度很正常，其它各项指标也是正常，只能先将这台服务器切流，初步怀疑这台服务器的MQ消费有特殊的问题 。

另外跟踪几个消费的消息，发现有个数据库查询方法特别耗时，致使整个消息处理变慢

查看其它服务器的消息处理状况，这个查询方法速度虽然也要一到两秒，但也算是正常。但这台机器查询速度慢应该是受到服务器CPU高负载的影响，毕竟redis和JDBC链接也会受到影响。

将这台服务器暂时切下，等待消息处理结束，服务器就自动恢复了，可是是什么引发服务器的CPU负载升高的“元凶”还没找到，怎么也解释不通，还须要继续观察。

---

小结：

一、学习到简单定位占用CPU高的线程在作什么操做的服务器命令 二、ActiveMQ这个消息中间件仍是不熟悉，须要去了解一下 三、dao层查询慢，业务上须要进行优化这个场景 四、要去了解服务器各类状态的影响

---

参考资料：

一、服务器TIME_WAIT和CLOSE_WAIT详解和解决方法

二、ActiveMQ源码解析（二）会话是什么