Doris 4.0.3 BE内存

这是让AI 分析的结果。

一、基本概况

当前 RSS 44.60 GB，距离 55.60 GB 硬限制还有约 11 GB 空间，暂未触发 OOM，但已超过软限制 50.04 GB 的 89%。

二、内存分层拆解（核心）

进程 RSS: 44.60 GB
├── TrackedMemory（已追踪）: 9.77 GB  ← 仅占 22%
│   ├── TasksMemory: 430.97 KB （当前空闲）
│   │   ├── Query: 0 (Peak 6.15 GB)
│   │   ├── Compaction: 169.30 KB (Peak 3.86 GB)
│   │   └── Load: 261.67 KB (Peak 1.89 GB)
│   ├── CacheMemory: 2.37 GB
│   │   ├── DataPageCache: 1.05 GB
│   │   ├── PKIndexPageCache: 1.12 GB
│   │   ├── IndexPageCache: 110.93 MB
│   │   └── MowDeleteBitmapAggCache: 88.61 MB
│   ├── MetadataMemory: 2.36 GB
│   │   ├── SegmentCache: 2.29 GB ← 最大头
│   │   ├── Rowsets: 64.56 MB
│   │   └── Tablets: 7.33 MB
│   ├── JemallocMemory (tracked): 4.78 GB
│   │   ├── Cache (tcache+dirty): 2.81 GB
│   │   └── Metadata: 1.97 GB
│   ├── GlobalMemory: 265.94 MB
│   │   ├── S3FileBuffer: 200 MB (Peak 5.08 GB)
│   │   ├── IOBufBlockMemory: 38.75 MB
│   │   └── BlockCompression: 27.19 MB
│   └── MemtableMemory: 0 (Peak 8.63 GB)
│
└── UntrackedMemory（未追踪）: 34.83 GB  ← 占 78%，核心问题！

三、核心问题：34.83 GB 未追踪内存

这是这台 BE 最突出的问题。78% 的 RSS 不受 MemTracker 监控，意味着 Doris 的内存 GC 机制无法有效管理这部分内存。

未追踪内存的去向分析

通过 jemalloc 统计交叉验证：

关键差值：

• jemalloc allocated (37.74 GB) - Tracked (9.77 GB) = ~28 GB 已被 jemalloc 分配但 Doris MemTracker 未追踪
• jemalloc active - allocated = 3.92 GB 内部碎片
• jemalloc resident - active = 4.02 GB (元数据 + 脏页)

未追踪内存的可能来源

1. ObjectHeapDump 中的元数据对象（约 1.58 GB 可见的）：

   • ColumnReader: 562.92 MB (1.23M 个)
   • SegmentMemBytes: 564.77 MB (18K 个)
   • OrdinalIndexReader: 206.07 MB (1.23M 个)
   • ZoneMapIndexReader: 166.17 MB (1.21M 个)
   • RowsetMeta: 51.54 MB
   • 这些对象本身的内存加上它们引用的深层子对象，可能远不止这些

2. S3 相关读写 buffer：Peak 达到 5.08 GB，当前虽回到 200 MB，但可能有 jemalloc 碎片残留

3. jemalloc 碎片与保留：

   • 内部碎片 ~3.92 GB
   • 元数据 1.97 GB
   • 脏页 1.99 GB
   • 合计 ~7.88 GB 的 jemalloc 开销

4. ColumnReader 数量过多：1.23M 个 ColumnReader 本身占 562 MB，但每个 ColumnReader 内部还有指针、索引结构等，实际内存占用可能远高于统计值

四、Cache 使用情况

磁盘文件缓存（File Cache）命中率：76.3%，两个磁盘各 ~450 GB 容量，已使用约 146 GB。

五、任务内存情况

当前几乎无活跃查询和写入任务：

• Query：当前 0，Peak 6.15 GB
• Load：有约 20 个 StreamLoad 任务，但绝大多数已完成，当前仅 ~132 KB
• Compaction：1 个 BaseCompaction 在跑，仅 169 KB；Peak 达 3.86 GB
• MemtableMemory：当前 0，Peak 8.63 GB（说明曾有大批量写入）

六、建议与优化方向

1. 应对未追踪内存高（最紧急）

这是 Doris 4.0.3-rc03 版本可能存在的 MemTracker 覆盖不全的问题。建议：

• 升级到正式版或更新版本：rc 版本的 MemTracker 可能有 bug 或覆盖不全
• 开启 enable_memory_orphan_check=1（已开启），观察日志中是否有 orphan memory 报警
• 考虑设置 enable_shrink_memory=true（当前为 false），让 BE 主动收缩 jemalloc 内存

2. 降低 jemalloc 碎片与元数据开销

当前 jemalloc 元数据 1.97 GB + 碎片 3.92 GB = ~6 GB 的内存浪费：

• dirty_decay_ms 和 muzzy_decay_ms 当前均为 5000ms，可以考虑降到 1000ms~2000ms 加速脏页归还
• 线程数 1934 × tcache，总 tcache 352 MB，可以考虑适当缩小 tcache_max

3. 控制 SegmentCache

SegmentCache 当前 2.29 GB，且 enable_segment_cache_prune=0（关闭了 prune）：

• 建议设置 enable_segment_cache_prune=true，或降低 segment_cache_memory_percentage（当前 5%，即 ~2.78 GB）
• ColumnReader 数量达 1.23M，说明 SegmentCache 中缓存了大量 Segment 的列信息

4. 监控 S3FileBuffer 峰值

S3FileBuffer 峰值达 5.08 GB，说明在大查询/写入时对象存储 IO 会消耗大量内存 buffer。如果内存紧张，可以关注是否有大量并发 S3 读写。

5. PKIndexPageCache 偏高

1.12 GB 的 PK Index Page Cache 说明 MOW（Merge-on-Write）表较多。当前 pk_storage_page_cache_limit=10%（约 5.56 GB），如果内存紧张可适当降低到 5%。

七、总结

最关键的行动项：调查和解决 34.83 GB 未追踪内存问题。优先考虑升级到正式 release 版本，并开启 enable_shrink_memory、enable_segment_cache_prune 来回收部分可控内存。