存算分离CN节点总是内存耗尽奔溃

💬 StarRocks 用户问答 性能相关
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】问题详细描述
【背景】做过哪些操作？
【业务影响】
【是否存算分离】
【StarRocks版本】例如：4.0.0
【集群规模】例如：1fe + 1cn
【机器信息】FE 4核16G CN 8 核16G

我的数据量不大，一天导入量在200mb以内。是通过 Stream Load每分钟导入一批，按租户分表，通过FE节点的:8030/system?path=//statistic 查看目前总表数1.6万个，启动运行1天左右CN就耗尽内存奔溃了。

我的CN有配置：
storage_root_path = ${STARROCKS_HOME}/storage

mem_limit = 70%

但是内存还是耗尽导致CN节点奔溃。

不知道是什么原因？是不是无论多大的数据量CN节点都要64G内存起步？我之前FE节点买8G内存就奔溃过换16G内存就正常了。CN节点因为目前我只是导入数据我以为16G内存就够了，还没有开始复杂的分析查询就奔溃了。是不是CN节点也和FE一样会完整的将所有的元数据都放到内存里？

#2

您遇到的 CN 节点内存耗尽并崩溃的问题，很可能与您 1.6 万张表 的数量以及 StarRocks 的内存管理机制有关，特别是 CN 节点对元数据的处理方式。

核心原因分析：表数量过多导致的元数据压力

虽然您的 数据导入量 （200MB/天）很小，但 1.6 万张表 的数量对 StarRocks 的内存消耗是巨大的。

1. CN 节点与元数据

CN 节点（Compute Node） 的主要职责是查询计算，但它也需要维护一份**元数据（Metadata）**的缓存，以便进行查询规划和数据路由。

  • FE 节点（Frontend） ：FE 节点是元数据的核心管理者，它将 所有 元数据（包括数据库、表、分区、索引、统计信息等）完整地加载到内存中。您从 8GB 升级到 16GB 解决 FE 崩溃问题，正是因为元数据量超过了 8GB 的限制。
  • CN 节点 ：CN 节点虽然不存储完整的元数据，但它会从 FE 同步并缓存必要的元数据信息。 表数量越多，CN 节点需要缓存的元数据对象就越多，占用的内存就越大。 即使是元数据的缓存，1.6 万张表也会产生巨大的内存开销。

2. 内存消耗的组成

CN 节点的内存消耗主要包括：

  1. 元数据缓存： 1.6 万张表的元数据对象。
  2. 查询执行内存： 即使是 Stream Load 导入，CN 也会参与数据预处理和写入，需要内存来处理导入任务。
  3. Tablet/Segment 句柄： 维护大量表的 Tablet 和 Segment 句柄也会占用内存。

3. 内存碎片和 JVM 压力

CN 节点（在 StarRocks 3.x 版本中，CN 节点通常基于 C++ 实现，但其内部组件和依赖可能仍有内存管理开销）和 FE 节点（基于 Java/JVM）都会面临内存压力。

  • FE 内存： 1.6 万张表的元数据可能已经占用了 16GB FE 内存的大部分。
  • CN 内存： 即使 CN 节点设置了 mem_limit = 70% ，如果元数据缓存和导入任务的内存需求超过了剩余的 30% 或总体的 16GB 限制，就会导致 OOM（Out of Memory）崩溃。

结论和建议

是的，对于您这种表数量极多的场景，CN 节点也需要较大的内存配置。 内存需求不是由数据量（200MB/天）决定的，而是由**元数据量（1.6 万张表）**决定的。

1. 内存配置建议

  • CN 节点： 16GB 内存对于 1.6 万张表来说是不足的。 建议将 CN 节点的内存升级到 32GB 或 64GB 起步 ，以确保有足够的空间容纳元数据缓存和后续的查询计算。
  • FE 节点： 既然 16GB 已经稳定，可以暂时保持，但如果未来表数量继续增加，FE 内存也需要相应提升。

2. 架构优化（更重要的长期解决方案）

按租户分表（1.6 万张表）在任何 OLAP 系统中都是一个极端的做法，会给系统的元数据管理带来巨大压力。

强烈建议您重新设计表结构，使用一个或少数几个大表，并通过列来区分租户：

  • 使用一个大表 + 租户 ID 列：
    • 创建一个统一的表，包含一个 tenant_id 列。
    • 所有租户的数据都导入到这个大表中。
    • 查询时，通过 WHERE tenant_id = 'xxx' 来过滤数据。
  • 使用分区（Partition）或 Colocate Group：
    • 如果租户数量可控，可以考虑使用分区来管理数据生命周期，但 1.6 万个分区也是一个巨大的数字。
    • 如果查询隔离性要求高，可以考虑使用 StarRocks 的 Colocate Group 或 Database 来进行逻辑隔离，而不是物理分表。

这样做的好处：

  • 大幅减少元数据： 表数量从 1.6 万降到 1 个或少数几个。
  • 降低内存消耗： FE 和 CN 节点的元数据压力将彻底解除。
  • 提高查询效率： 优化器在处理少量大表时效率更高。

总结： 请先尝试升级 CN 节点的内存到 32GB 或 64GB 来解决当前的崩溃问题。同时，将表结构优化（从 1.6 万张表改为少数几张大表）作为长期和根本的解决方案。

#3

非常感谢您的完整详细深度回答！我现在已经有了一些优化的思路了。

我在你们官方文档看到如下文档：

选择分区键

  1. 时间优先默认 ——如果 80% 的查询包含时间过滤器，则以 date_trunc('day', dt) 开始。
  2. 租户隔离 ——当需要按租户管理数据时，将 tenant_id 添加到键中。
  3. 保留对齐 ——将计划清除的列放入键中。
  4. 复合键 ： PARTITION BY tenant_id, date_trunc('day', dt) 可以完美裁剪，但会创建 #tenants × #days 个分区。保持总数低于 ≈ 100 k，否则 FE 内存和 BE compaction 会受到影响。

PARTITION BY tenant_id, date_trunc(‘day’, dt) 这个就是通过租户分区的方式，但是starrocks貌似有数量限制在100 k，我担心这个限制范围，所以采用了租户分表的形式。我想知道如果大表按租户ID，而又需要按租户每周或每月分区，自动分桶，实际的表数量是不是和分表一样？#tenants × #days个分区（表数量应该是包括分区）因为我看到这里的描述，而且这个有上限（保持总数低于 ≈ 100 k）

还是说，可以不用PARTITION BY tenant_id, date_trunc(‘day’, dt)按租户分区裁剪而是直接采用PARTITION BY date_trunc(‘week’, createdAt)，通过tenant_id租户来查询日期范围也非常快？

我的实际生产环境场景下租户数量实际总数会保持在1000个左右，1.6万是我通过不同分析指标的数据划分了多个数据库（大概10个类别的数据库，全是明细表），然后有做按周或者按月分区，昨天通过:8030/system?path=//statistic统计结果来看是1.6万（貌似分区、索引都算表数量），今天观察涨到了2.3万（应该是部分表按周分区今天是周一又增加了很多分区）。

请教下我这样的场景怎样设计表结构更好，感谢！

WX20251027-182554@2x
WX20251027-182554@2x3368×1612 384 KB

京ICP备2022026421号-1