[GitHub] [dubbo] hexufeng commented on issue #1784: Dubbo调用超时，服务端历史统计的处理耗时很短且找不到对应超时上下文的超时日志

["hexufeng (via GitHub)" <gi...@apache.org>]

hexufeng commented on issue #1784:
URL: https://github.com/apache/dubbo/issues/1784#issuecomment-1501813170

   > 所以，这个问题最终没有答案，还被close掉了？
   
   我最终解决了我们遇到的问题，下面分享下我们遇到的现象和解决过程
   
   现象：每次服务发布后dubbo provider 会在发布后的十几分钟内不再响应，consumer端异常显示provider端的dubbo线程池被打满，类似这样的错误信息
   ```
   Thread pool is EXHAUSTED! ...
   ```
   
   但我们监控平台在服务provider侧监控不到任何有用的信息，连错误信息都没有。但通过对线程池的监控发现DubboServerHandler线程池的数量从发布后到无响应线程数一直增加，直到满为止，时间吻合。
   
   于是，我们判定每次发布后无响应，客户端同时也会有一些报超时的错误 的现象，是由于provider端的线程池被打满导致的。
   
   
   排查：通过配置增大provider端线程池，无用。从AbortPolicyWithReport类（DubboServerHandler线程池的拒绝策略实现）中发现，线程池满后dubbo会调用一个方法
   ```
   dumpJStack(); 
   ```
   查看该方法内部发现确实dump了堆栈信息，于是我们从服务器上找到了该日志文件，下载后通过jstack分析，发现线程池打满时刻，DubboServerHandler线程池中的所有线程均RUNNING状态，表明未发生死锁，排查发现有非常多的同一个接口调用，于是问题明了了：
   该接口对应的底层数据库查询数据量太大，查询很慢，当发布的时候用户着急重复刷新页面提交该查询请求，导致不断积累又不返回，线程池很快被占满。
   
   最后的疑问：
   为何发布后发布的机器会被打满而未发布的其他机器却没事？按理说负载均衡后请求路由会均分到所有可用的机器上，但我们遇到的现象是被发布的机器偶发这种现象，集群里未被发布的机器却没事。
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org