CPU调优总结

缘由：应用启动后，在未作调用时cpu占用20%-30%

这确定是有问题的，严重影响压测质量和存在线上风险，因此开始排查。

下面将详细写出排查和分析过程。

 

1，确认问题

登陆 三台服务器，top (或者vmstat 1)一下，查看cpu占用状况：

三台机器都很高，并且还未有调用量， 有问题。

登陆IMSI销售接口服务器对比查看：

能够肯定应用不正常了。开始解决。

 

2，解决过程

• 由于是cpu高，内存不高，因此肯定是线程问题，因此去到问题服务器抓取线程
  
  ./jstack  xx >> /home/admin/jstack.log    （xx 是应用的进程号）
  将线程日志搞到跳板机 再搞到本地分析。
  
  线程分析工具用的是 jca，打开查看：
  
  
  而正常的应用:
  
  
  问题应用runnable 线程居然有900多，waite线程不会占用cpu资源，暂时不用分析。点击详细：
  
  

      

          发现大量的NettyClientSelector， 嗯？ 这应该是hsf的线程吧！（这里分析是错的！！！） 然而忽略了最重要的MQ-AsyncArrayDispatcher-Thread-XX，这个后面会详细写。

          而后后面作了一些对hsf的配置优化，进入edas的后台能够查看到有大量的无用的consumer，这对edas的压力是很是大的，随着之后服务愈来愈多，配置愈来愈多，会对线上存在隐患，因而进行精简，抽取本地的 consumer配置文件。

           再次上线， 分析。。 发现问题依旧， 崩溃。  从头再来。 

• 仍是找到问题进程
  
  咱们看看这个进程里的哪些线程在占用cpu：
  top -p 进程id -H
  
   (这个图是解决问题后截取的，没解决时，cpu占比每一个都在0.6-1左右，是很是高的)
  
  红框里是线程id，是10进制的，jstack.log 里是以16进制展现的，因此须要转换，到文件里找到对应的线程号。

          

发现查了好多都是 AsyncArrayDispatcher$AsyncRunnable.run 这个方法。

继续分析这个东西是干吗的，找代码。

发现这是一个守护线程，应该是为每一个新建立的topic 提供一些系统的记录功能。

瓶颈期到了，想找找哪里应用到了这个类，但是都在阿里的jar里，找起来很费劲，并且不肯定在哪，有可能还会在潘多拉里，找了好久的class源码，无果，这里耽误了好久的时间。

后来转换方向，由于imsi_sale是正常的，因此肯定不会是底层的BUG致使的，仍是把目标转向应用自己的配置，并且跟MQ相关的。

查看mq相关的配置，惊奇的发现，居然这么多无用配置。

 。。。

将近 100多，期间咱们找了天源的人给看了topic的默认线程数是5个，这么算来也得启了几百的无用线程，跟问题线程数也很接近。

究竟是不是呢？ 又找了代码，发如今 base_impl包里真的有：

 

不得不说隐藏的很深，有点坑。 这些东西应该是放在配置文件里，咱们能看见的地方的。

好吧，终于肯定问题了，精简配置文件，上线， 解决！

注： 其余应用也存在这样的问题， 都须要修复一下。