部署结构： 3BE+3FE 独立服务部署，SSD 磁盘。
排查过程：
其中BE01 节点cpu 高，负载高，其它BE节点和FE 节点都正常，发现这个BE01节点的磁盘读取非常高，达到400M/s 如截图：
BE01服务当时的线程如截图：
建议perf top看一下
又重现了，麻烦大佬看一下
能否帮忙诊断下这个be IO 异常的点呢？没排查出问题 不敢使用这个starrocks了
+1 同样的问题，偶尔磁盘IO会飚高。到500MB/s，影响查询
请问下是用的哪个版本？导入频率是多少？另外负载高的时候麻烦抓下pstack $be_pid
磁盘IO需要确认下同时间段是否有大量导入或者大数据的查询
导入数据的场景描述下，哪种导入方式，频率多高或者当前sink的触发条件是啥？目标表是什么模型？
flink读kafka写StarRocks
调用：Stream Load
sink：10s一次
目标表：大部分为主键模型
版本：2.1.3-0881cb2，flink 增量导入频率15s ，磁盘写入不高，就是IO 读取高，其它be节点 完全正常，用的是主键模型。
当时几乎没有业务查询，只有flink-cdc 导入任务。
flink日志里面搜下_stream_load，看下实际多久sink一次
你好，请问下，sink频率高，会影响compaction频率从而影响查询IO么。
我的理解是主键模型表白天只会做增量合并，扫描部分需要合并的数据。扫描的数据量并不会很大
base compaction默认的开启时间是base_compaction_start_hour 和base_compaction_end_hour，20点到7点，那么白天没有base_compaction，读IO应该不会特别高吧
会的，目前建议10s+一次写入，频率高了会给compaction带来压力。
另外看下有问题be的be.out
如果我sink从10s调整成20s，那么需要compaction的数据量总量不变吧.
这样是不是把单次compaction的数据量变高了，IO压力反而更高了
假设：第一次compaction需要合并100M，第二次也需要合并100M
修改完后，第一次compaction需要合并0M，第二次需要合并200M
be.out 出问题的时候没什么输出，出问题前一天输出的，内容和其它正常的be节点一样，如下：
start time: Sat May 7 21:14:52 CST 2022
start time: Sun May 8 11:28:25 CST 2022
tcmalloc: large alloc 1195728896 bytes == 0x123d88000 @ 0x4e98709 0x50163dc 0x1ceab18 0x4f66c75
tcmalloc: large alloc 1246912512 bytes == 0x2f7b64000 @ 0x4e98709 0x50163dc 0x1ceab18 0x4f66c75
tcmalloc: large alloc 1648500736 bytes == 0x493950000 @ 0x4e98709 0x50163dc 0x1ceab18 0x4f66c75 0x1c0343d 0x17da5f8 0x17dbe09 0x17655bc 0x175a2cf 0x4fe0870
tcmalloc: large alloc 3347611648 bytes == 0x6c68f2000 @ 0x4e98709 0x50163dc 0x1ceab18 0x4f66c75 0x1c0343d 0x2e57bdc 0x2e58d59 0x2e4473a 0x1c6c1e4 0x1c6d402 0x1c66111 0x1c63ee6 0x3680bce 0x3677637 0x36784e3 0x371f22e 0x37c3f9f 0x37b8511
在这台be上面执行下addr2line -e lib/starrocks_be 0x4e98709 0x50163dc 0x1ceab18 0x4f66c75 0x1c0343d 0x2e57bdc 0x2e58d59 0x2e4473a 0x1c6c1e4 0x1c6d402 0x1c66111 0x1c63ee6 0x3680bce 0x3677637 0x36784e3 0x371f22e 0x37c3f9f 0x37b8511