BE节点磁盘io打满，有查询任务报错

[xiao]

【详述】BE节点磁盘io打满，有查询任务报错。
【背景】无
【业务影响】有查询任务报错
【是否存算分离】否
【StarRocks版本】例如：2.5.11
【集群规模】例如：3fe+7be (部分FE和BE混部)
【机器信息】12C/48G
【联系方式】社区群3-Mr。xiao
【附件】
收到业务侧反馈有查询任务超时和报错，查看监控，发现BE磁盘IO打满，并持续了几分钟时间。

我之前在各个BE几点上部署了lsof的监控脚本，发现在IO高相同的时间段，有个index.tmp文件生成并转换为正式文件，大小为30G。
2024-05-13 12:54:23左右生成了/data1/starrocks/be/storage/data/811/4836406/1889091023/index.l1.1843458.0.tmp文件，
2024-05-13 12:57:51左右，变成/data1/starrocks/be/storage/data/811/4836406/1889091023/index.l1.1843458.0的正式文件了

该文件大小为30G，因此分析这一时间段IO持续打满，可能和该文件读写有关，不知道这个index文件为什么这么大？

这个index的表为主键模型表，数据量为39w+，表结构如下：

在13:10分左右，还是这张表的另一个tablet下的index文件，也是同样的问题，30G的大小文件，从生成index.l1.1843548.0.tmp到变成index.l1.1843548.0的过程中，这个时间IO也被打满了。

[trueeyu]

be.con update_compaction_size_threshold=67108864 试试， 最好是升级到2.5.20,然后改下这个配置看看。你这个表有多大数据量，1个Tablet特别大？

或是升级到3.1.11

[xiao]

update_compaction_size_threshold我们现在是33554432，我调整到67108864试试，这个表目前39w+的数据量，每天会有读写和删除更新操作，为啥这个index文件这么大，这个是已知问题吗？因为是生产环境，升级我们得先评估下。
单个tablet不是很大

[trueeyu]

如果以前是32M，就不需要调了

[trueeyu]

那只能通过3.1.11上的优化来做了，或是分桶配置的多点

[trueeyu]

你当前用的这个版本是2.5.11吗？

[xiao]

是的，是从2.5.2升级到的2.5.11

[xiao]

这个是什么原因导致的呀

[zhangqiang]

给个日志看下？

[xiao]

需要哪些日志

[zhangqiang]

就你看到这台BE这个时间段的日志就行

[xiao]

be.INFO.log.zip (6.2 MB)

[xiao]

这是这台BE的io监控，拿了12:50-13:10之间的日志

[xiao]

3.1.11是优化了啥

[xiao]

这个之前也出现过好几次就是io突然被打满了然后自己又降下来了，当时没找到是这个index文件的变化，后来弄了个lsof的脚本定时抓取，才发现了这个index文件有异常。

[zhangqiang]

什么时候升级的？

[xiao]

去年8月30日吧 升级到的2.5.11，部署是2.5.2，然后升级到的2.5.7，再升级到的2.5.11

[zhangqiang]

还知道这张表是什么时候建的吗

[xiao]

挺早的了，不过这张表后来因为业务需求，好像有drop掉重建过

[zhangqiang]

看了下日志，应该是这个问题 https://github.com/StarRocks/starrocks/pull/34352 ，运行时间久了积攒起来导致这个index文件太大了，考虑升级下？