doris 2.1.7,BE的上限为 46G。
现像:从 6月9号开始,BE内存异常上升,而且不释放,且呈现周期性起落,重启BE仍不能解决问题,如下图:
还有一个现像:从 6月9号BE内存异常上升后,BE内存呈现周期性的起落,其周期为2分钟,如下图:
重启FE后,内存回收有了变化,如下:
doris 2.1.7,BE的上限为 46G。
现像:从 6月9号开始,BE内存异常上升,而且不释放,且呈现周期性起落,重启BE仍不能解决问题,如下图:
还有一个现像:从 6月9号BE内存异常上升后,BE内存呈现周期性的起落,其周期为2分钟,如下图:
重启FE后,内存回收有了变化,如下:
我作了以下 2 个尝试:
1、我在23:30 关闭FE,发现BE的内存使用率仍然没有下降,而且仍然有锯齿状的起伏。
2、在关闭FE的情况下,重启BE,发现BE的内存使用率很快就上来了,并恢复最初的有问题时的样子。如下图:
第二天观察仍然两个问题现像仍然存在:
1、内存平均使用率在 30G左右
2、内存周期性的上升下降,其周期为 2 分钟。
根据 徐老师的建议,我们检查了 compaction,从日志中发现 compaction 存在失败的情况,日地详情如下:
W20250614 10:08:12.864840 116960 tablet.cpp:2072] failed to do base compaction, tablet=1998836 : [MEM_LIMIT_EXCEEDED]PreCatch error code:11, [E11] Allocator sys memory check failed: Cannot alloc:233918, consuming tracker:, peak used 338179228, current used 46031078, exec node:<>, process memory used 62.76 GB exceed limit 62.67 GB or sys available memory 21.23 GB less than low water mark 6.27 GB.
而且是同一个 tablet_id,一直失败,这时感觉发现了问题背后的真像,于是我们去检查该 tablet_id 对应的表,发现该表只有 1000多行数据,但其体量有 7G多,那么肯定使用了某些大字段。查看表结构,果然发现了bitmap 类型的字段。
可是为什么这个表 compaction 会失败呢?通过show create table 发现,其BUCKETS的值 为 1,到这里真像找到了。compaction 需要以tablet 为单位进行,这里 BUCKETS的值 为 1,而且没有分区,所以 tablet 也只有一个,所以导致 compaction 因内存不够失败。
解决问题,重建表,然后把 BUCKETS的值设为 16,问题解决。
感谢 徐老师指点了正确的方向。