记一次线程池资源耗尽问题排查

问题描述

这边有一个项目基于开源项目ThingsBoard，Github链接是https://github.com/thingsboard/thingsboard。具体是这样的，在上线后，开始系统各个模块正常运作，但是从规则引擎界面配置调用外部接口采集数据后，经过3~4小时，包括登录接口在内的系统前端交互接口均开始出现接口503。且重启后问题复现，无法自行恢复。规则引擎侧采集的设备信息也同步停止新增。

问题分析

思路是这样的。若系统不调用数据采集接口进行设备信息采集，则线上无问题。数据采集接口如何影响前端UI界面的正常请求？没错了，答案就是：资源耦合！
顺着这个思路排查到了如下代码：

可以看到ThingsBoard里这个数据库请求都是包了一层异步。然后这边项目里数据库有mysql和tdengine（一款国内研发的时序数据库：https://www.taosdata.com/）。最终定位到了耦合的资源，如下图：

可以看到前端用户请求 -> 线程池(ForkJoinPool) -> 连接池(HikariPool) -> mysql。规则引擎 -> 线程池(ForkJoinPool) -> 连接池(HikariPool) -> tdengine。两者使用了同一个线程池做异步，线程池设置为16。mysql连接池大小16，tdengine连接池大小20且未设置超时。这个公用的线程池资源耗尽导致前端请求阻塞超时！那么接下来又来了一个问题：td请求阻塞还是mysql请求阻塞？

jstack日志分析

从jstack线程栈日志看出，ForkjoinFool里阻塞的task都是tdengine的！

jvm dump分析

从JVM dump信息中查看程序运行时正在执行的数据库SQL请求情况。通过源码追踪可知，所有数据库SQL请求均被封装为HirariProxyPreparedStatement，而系统异常状态下，共计16个正在运行中的HirariProxyPreparedStatement同时存在，与JpaExecutorService线程上限一致，且所有SQL均是TdEngine的插入操作。至此真相大白！

结论

总结下来，这其实是一个比较典型的线程池资源耗尽问题。针对线程池资源耗尽问题，最好的处理方式是让Mysql和TdEngine使用单独线程池，达到资源解耦目的，但是该方案需要修改代码，上线审批流程较长。因此，作为临时方案，可修改配置文件，增加最大线程数，并同时设置TdEngine连接池超时时间，使得线程池资源在TdEngine请求都超时的最坏情况下依然能正常工作。