fe/be节点cpu和内存不是特别高，其中一台BE线程数过高，sql查询会被阻塞

[dongweizhao]

问题描述：

查看fe、be节点cpu和内存都不是特别高

但是查询sql偶尔会被阻塞

通过监控分析，发现有一台BE的线程数在持续增加，最后出现以上问题

分析查询延迟，在9点45至11点持续很高

问题复现的case：

没法复现，只能等下次出现了

Doris版本：

0.15

Doris集群基本信息：

3台FE 机器 配置：16C 32G 500G   
3台BE 机器 配置：16C 32G  1T   
分别独立部署

异常信息：

查看be日志，线程数过高的be一直在打印以下日志

I0309 10:53:12.018661 24339 fragment_mgr.cpp:675] FragmentMgr cancel worker going to cancel timeout fragment 6131364aced24696-ac85307426e46083
I0309 10:53:12.018664 24339 fragment_mgr.cpp:675] FragmentMgr cancel worker going to cancel timeout fragment 6d2b4efe9bc74df2-8365ca6a8b777d64
I0309 10:53:12.018667 24339 fragment_mgr.cpp:675] FragmentMgr cancel worker going to cancel timeout fragment 759d81f909b94b4c-941031a9868c0f56
I0309 10:53:12.018671 24339 fragment_mgr.cpp:675] FragmentMgr cancel worker going to cancel timeout fragment e7777f7bee234909-ac49e35874f3b62b
I0309 10:53:12.018673 24339 fragment_mgr.cpp:675] FragmentMgr cancel worker going to cancel timeout fragment edf2d791f492475b-8769b9d2703314bc
I0309 10:53:12.018676 24339 fragment_mgr.cpp:675] FragmentMgr cancel worker going to cancel timeout fragment cecf2feff65d43ae-812a75b49b84c2dc

而其他2台be日志正常

临时解决方案

因为是生产环境，所以目前采用了快速重启方案，并增加了以下指标的监控，但是只能治标不治本

99th Latency 每个FE 的 99th个查询延迟情况，大于2s进行预警
BE thread num  各节点值进行比对，如果差值大于200则进行预警
Connections 当前连接数大于前一小时的连接数的2倍，则进行告警

解决方案（社区技术人员或者其他用户给出的回复解决方案）

Originally posted by @hf200012 in #8411

[dataalive]

最近还出现该问题吗

[dongweizhao]

最近还出现该问题吗

最近没有出现