【详述】问题详细描述
【背景】
没有发现数据倾斜情况
tablet的分布情况:
【业务影响】
【StarRocks版本】2.0.0-GA-2ffdf30
【集群规模】例如：3fe（1 follower+2observer）+8be（fe与be混部）
可以看下那个时间节点是否存在比较多的大查询或者导入，命中了其中一台be，导致一个节点的内存占用上升了
从内存使用情况看，BE节点是持续性的内存使用高，并不是偶发性的命中
那看看占用高的哪个节点是不是fe/be混部的节点，如果是leader节点的话，混部的监控会是有一台内存比较高的现象时正常的
图上绿色线是混布的BE/FE节点，紫色线是单纯的BE节点
现在还是有一台be的内存比其他高吗。
curl -XGET -s http://BE_IP:BE_HTTP_PORT/metrics | grep “^starrocks_be_.*_mem_bytes|^starrocks_be_tcmalloc_bytes_in_use”
命令可以看到be的内存消耗明细，可以找个参考机器，和占用高的机器，分别执行下，看看内存差异
2.4版本开始一些监控项名称做了修改，所以现在这个命令获取到的结果为空，2.4+版本直接使用curl -XGET -s http://BE_IP:BE_HTTP_PORT/metrics | grep "^starrocks_be_.*_mem_bytes"就可以了
异常服务器内存：
正常服务器内存：
2.1+版本，已修过这个问题
是什么原因呢，如果不升级版本怎么解决的
Compaction占用内存过高导致，2.1+的版本修了了Compaction机制，可以完美解决这个问题
想了解一下，为什么load返回状态是finish但是compaction还在使用内存，运行机制是什么样的
Compaction是异步做的
建表时的排序规则会对load数据的时候会对compaction有影响吗，或者会影响BE内存等情况