ByConity 项目中 Server 内存缓慢增长问题的分析与解决方案

问题现象

在 ByConity 0.4.2 版本部署环境中，运维人员观察到 Server 节点的内存使用量呈现缓慢增长趋势。具体表现为：

• 两个 Server Pod 的内存限制设置为 7GB
• 其中一个 Pod 内存使用增长至 4.7GB 时，探活失败触发自动重启
• 监控数据显示内存增长过程持续约七天时间

排查过程

初步诊断

通过查询系统异步指标表，技术人员首先检查了各种缓存的使用情况：

SELECT
    *,
    formatReadableSize(value) AS cacheSize
FROM system.asynchronous_metrics
WHERE metric LIKE '%Cache%'
ORDER BY value DESC
LIMIT 15

查询结果显示：

• 操作系统缓存(OSMemoryCached)占用约6.26GB
• 其他缓存如CnchPartCacheParts、UniqueKeyIndexMetaCacheBytes等占用较小(几百KB级别)
• 未观察到UncompressedCache和ChecksumsCache等关键缓存的指标数据

深入分析

进一步检查发现：

1. 虽然配置文件中已配置uncompressed cache和checksum cache参数，但在Server节点上未能查询到相关指标
2. Worker节点上可以正常显示这些缓存指标，说明配置在Worker端生效
3. 通过直接连接高内存使用的Server Pod进行诊断，确认问题与常见缓存配置无关

问题根源

经开发团队确认，这是ByConity 0.4.2版本中存在的一个已知内存泄漏问题：

• 属于Server端的内存泄漏缺陷
• 泄漏速度较慢，难以通过常规监控指标直接观测
• 该问题已在1.0.0及后续版本中修复

解决方案

针对不同版本的建议：

1. 对于0.4.2版本用户：

   • 临时解决方案：定期重启Server节点以释放积累的内存
   • 长期建议：升级到更高版本

2. 对于考虑升级的用户：

   • 1.0.0版本已修复此内存泄漏问题
   • 1.0.1版本进一步修复了Kafka消费异常等问题
   • 建议升级到1.0.1或更高版本以获得完整修复

技术建议

对于使用ByConity的企业用户，建议：

1. 建立完善的内存监控体系，包括：

   • 基础内存使用监控
   • 各组件内存分配跟踪
   • 关键缓存使用情况监控

2. 对于关键业务系统，建议：

   • 保持版本更新，及时获取官方修复
   • 在生产环境升级前，先在测试环境充分验证

3. 对于必须使用旧版本的特殊情况：

   • 配置自动重启策略
   • 设置合理的内存阈值告警
   • 增加资源冗余以应对内存增长

总结

内存管理是分布式系统的重要课题，ByConity作为新兴的云原生数据仓库，在迭代过程中不断完善内存管理机制。用户遇到类似问题时，建议首先通过官方渠道确认是否为已知问题，并根据业务需求选择合适的解决方案。对于生产环境，保持系统版本更新是预防各类潜在问题的最佳实践。