版本：1.18.1
be+fe混部共三个节点
服务器资源16C+64G
问题描述：
be短时间失联造成使用问题。
根据后台监控显示，be老是有短时间失联的情况，入下图：
失联过程中，be task监控如下：
这段时间的性能开销也不大：
后台be没有报错，不知道各位小伙伴遇到过这些问题没有。
失联过程中，be task监控如下：
这段时间的性能开销也不大：
后台be没有报错，不知道各位小伙伴遇到过这些问题没有。
您可以使用show proc ‘/backends’ \G 查看一下be各个节点的LastStartTime ，截图看一下，可以将ip码住
抱歉，下午be重启了，暂时没有截图。问题点是be没有重启，只是这段时间卡住，连监控也采集不到任何数据。我看每次这段时间的io都很高，会不会是io打满导致这种问题呢？你们有测试过吗？
您能定位提供那个时间段be的节点的be.warning.log日志么？
io高可能也是一方面，因为会引起其他问题导致be连不上，这个要具体情况具体分析，你目前有查询多吗？不多的话 ，推测大概率是在做compaction，也会导致io偏高，您可以去到日志当中，看他输出的是什么，或者提供下那个时间段be的节点的be.warning.log日志，我们看下是否重启，重启了又是什么导致的
感谢您的关注，我这边观察了compaction不算高，只有几十。be重启是没有发生的，last start time还在昨天，我截图的是今天9点30左右的grafana监控到be dead的截图。be.warning.log相关日志已经截图在楼上了，走的是内网ip所以没打码。
1赞
blacklog打满了就是会让be服务掉线吗？该怎么解决啊？
您那边会出现打满的情况么？
打满应该出现过，就是执行groupby查询的时候数据量五亿，直接fe服务断联，我就感觉跟楼主情况很像，只不过他是be断联我是fe断联，还有我想问一下，启动be服务后jps查看服务是不是不显示be服务进程啊？
经过几天的观察，我现在比较相信是io打满，造成的超时问题，我们这边的用的腾讯云的SSD盘（普通版本，超级坑，可恨当时没调研清楚），读的io只有可怜的260M/S,稍微几个上千万的数据量的调度拉起来就不行了！就会出现be报failed to call frontend thift eagain timeout 之类的报错。（如图所示）
1赞
你的fe卡死我理解哈，是因为你的查询导致返回的数据量太大，打满io所以fe挂掉；而我这边一个sql可能只需要返回2条数据，但是是多个全表扫描+join，数据是分布式的，这些都需要be之间大量的io通信，所以我这边是be卡死。
你好，请教下你是如何判断io比较高的，能够贴出具体的命令和排查步骤吗？我这里也出现be偶尔断联的情况
你用的是哪个版本，2.5？
2.5.12也出现这种情况
是失联一段时间后恢复的，还是重启恢复的？
show backends 查看BE节点是正常的，监控上显示HEAD，之后自动恢复