ByConity 内存持续上涨问题分析与解决方案

问题现象

在 ByConity 0.4.2 版本的 Kubernetes 部署环境中，worker 节点（包括 vw_default 和 vw_write 虚拟仓库）的内存使用量呈现持续上涨趋势，没有明显的阶段性回收现象。每个 Pod 配置的最大内存为 32GB，且系统中使用了 Kafka 引擎。

排查过程

初始排查

技术人员首先检查了以下关键缓存参数的配置情况：

• mark_cache_size
• cnch_checksums_cache_size
• uncompressed_cache_size
• cache_size_to_ram_max_ratio

发现这些参数均保持默认配置未做调整。

缓存指标分析

通过执行特定的 SQL 查询，获取了系统中各类缓存的详细使用情况：

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

查询结果显示：

• ChecksumsCacheBytes 占用约 5GB
• MergeTreeDiskCacheBytes 占用约 3GB
• OSMemoryFreePlusCached 显示系统缓存约 2.5GB

在 vw_default 虚拟仓库中：

• MergeTreeDiskCacheBytes 占用高达 40GB
• MarkCacheBytes 占用约 110MB
• ChecksumsCacheBytes 占用约 68MB

关键发现

1. 未压缩缓存问题：系统未显示 UncompressedCacheBytes 指标，表明 uncompressed_cache_size 参数未被配置，导致该缓存无限制增长。

2. 默认配置风险：

   • mark_cache_size 和 cnch_checksums_cache_size 默认各为 5GB
   • uncompressed_cache_size 默认无限制

3. 内存分配：32GB 内存的实例内存使用已达 70%，存在潜在风险。

解决方案

1. 配置 uncompressed_cache_size

建议在所有 worker 节点的配置文件中显式设置 uncompressed_cache_size 参数，初始值可设为总内存的 1/3（对于 32GB 内存的实例，建议设置为 10GB 左右）。

配置示例：

<uncompressed_cache_size>10737418240</uncompressed_cache_size>

2. 其他缓存参数优化

根据实际业务需求，可考虑调整以下参数：

• mark_cache_size
• cnch_checksums_cache_size
• cache_size_to_ram_max_ratio

3. 监控建议

建立以下监控机制：

1. 定期检查各缓存指标
2. 设置内存使用阈值告警
3. 监控缓存命中率

实施效果

通过合理配置 uncompressed_cache_size 及其他缓存参数，可有效控制内存使用量的持续增长，使系统内存保持在稳定水平。同时，明确的缓存限制也能避免因缓存无限增长导致的内存溢出风险。

最佳实践

1. 生产环境必须显式配置所有缓存参数，避免依赖默认值。
2. 根据业务特点调整缓存比例，对于读密集型应用可适当增大缓存。
3. 定期审查缓存使用情况，根据实际使用效果优化配置。
4. 考虑工作负载特征，对于写入频繁的场景需要特别关注 MergeTree 相关缓存。

通过以上措施，可以有效解决 ByConity 系统中内存持续上涨的问题，保障系统稳定运行。