【详述】BE节点WARN日志报错，查询会超时
【背景】
【业务影响】
【StarRocks版本】2.3.1
【集群规模】3fe（1 follower+2observer）+3be（独立部署）
【机器信息】8C/64G/万兆
【详情】
be.warn偶发：
wait_for_version slow(79509ms)
wait_for_version timeout(60002ms)
看日志是在进行compaction，每次在该时间点，磁盘IO很高，部分查询会超时失败（这些查询正常可以在30s内返回数据）。超时参数没改过
请问有什么参数可以调优避免查询超时吗
我也是这样，插入查询延迟高，单表查询需要63s
兄弟们 升级2.4.0可以解决，赶紧升哈
升级后我遇到的问题：
1、跨库创建的视图在升级后需要重建，否则无法正常查询。
2、为了防止BE OOM，Bitmap_to_array有限制100W，用bitmap圈人的场景 需要调整对应参数
兄弟真的么，升级多久了，运行多久了 哈哈
跑了近一周 没什么问题
2.4版本刚公测，敢再生产上用么
被你言中，优化了一些问题，又有新的问题，回滚了
哎呦 多么不希望看到这个；你再成功了，我也换呀
第一个问题，是怎么复现的，可以聊下吗，
我们这场景是单表1.4亿，数据有小批插入和数据更新，直接对应用；因为插入和更新得比较多，导致be一直再合并版本导致插入和查询延迟高。
主键模型？高频导入？一次导入大欢插入多少条数据？
把副本设置为1可能会好一些
不好意思，上班忙没回；是的主键模型高频导入，每次插入100条；更新是单条，因为疫情没去现场，我估计新增得有100并发左右；服务器配置 128GB 32C 与es混合部署 2FE + 3BE
等你2.4.1版本了 
当前不适合一个批次这么少的情况啊，可以一个批次数据量多些，导入频率低一些吗？
直接和应用系统对接了；现在有两个问题请您帮忙回答下，1、一次写入多少合适；2、后续版本会不会支持这种场景
一个批次越大越好
以后会，但是今年应该不会了
收到，我再扩两台BE怎么样