一 . 系统说明：

A系统阿里云平台，5台集群，每台：1-2核，内存6G，带宽上限2M,磁盘1G。

基于tomcat容器，主要业务消费rocketmq，再pegion（服务治理工具）调用第三方服务。

同时接入20个左右topic的mq，并每一次mq都会调用一次第三方服务，第三方服务有B，C，D等系统，单台mq的qps 有几个（4个）比较大，一小时几十万。其他的比较小。

二. 问题：

5台集群一台的线程数量达到2500+，触发公司线程报警。其他四台也很高（2000+），但是还没到阀值。

三 .初步分析：

  1. 调用链

    看到线程数量大的这台a机器，调用B系统有多个请求时间到15S（调用超时时间是5S），并有10个左右调用失败，正常的都是1S以下，但是B系统的日志显示所有请求都是1S以下返回的。目前没有思路。

   2. threaddump

   2.1 活跃线程： 

      226个running Threads，194 个 "New I/O worker": running, holding...",活跃线程大部分是在epoolwait，应该是等着接收mq消息。

     

 

 

 

   2.2 全部线程：

                   

                

 

 

   1900+个线程都在线程池里空闲着，等待任务来执行。

   大致是：ConsumeMessageThread_X  有275个，NettyClientPublicExecutor_X 1024个，600+ 个线程池模样线程（pool-XX-thread-XXX）。

   分析下 ：

      （1）ConsumeMessageThread_X  是rocketmq的消费线程，epoolwait中，所以ConsumeMessageThread_X 也在等待。

                数量上参考下rocketmq源码，在：

        

 

 

        

有20个客户端，所以基本也是这个数量，这里最小需要20个线程吗？有些mq真的qps超级小。包装消费类时可以在start方法前面，set这两个值。并对外提供配置方式。

     （2）NettyClientPublicExecutor_X,NettyRemoteingClient.java ：这个线程是client做回调用的。

           

 

          private int clientCallbackExecutorThreads = Runtime.getRuntime().availableProcessors();

          所以应该是 可用processor有64个

              

 

这部分应该是云服务器的 物理服务器可用核太多，导致新建了很多无用的线程，其实这部分线程只做callback使用，数量应该也可以开发可配置。

 

 

 

 

 

 

 

 

   （3）pool-XX-thread-XXX

      有5（7，21，22，15，28）个线程池，每个线程池100+个线程，都是线程池里的线程空闲。

     这部分需要看下pegion的代码，惊奇地发现pegion这部分跟dubbo一样，近似看下开源的dubbo的代码

        

 

      大意就是各种threadpool用这个factory来生成线程，线程越来越多。没有源码很难看懂，从数量看也不是特别多，

        如果猜测下应该是调用外系统超时导致多起了一些线程来处理，后续线程未释放掉。

 

 

遗留问题：

rocketmq不常用线程数量可以配置等方式减少下

dubbo pegion线程池数量等有场景再分析下

dubbo个别服务调用时间长，这个目前还没有思路。

 

https://www.cnblogs.com/thinkqin/p/11794028.html

 

查看原文