ByConity 服务内存持续上涨问题分析与优化方案

问题现象

在 ByConity 0.4.2 版本的实际生产环境中，用户发现 server 和 worker 服务存在内存持续上涨的问题。具体表现为：

1. server 服务：内存持续上涨，只有通过重启才能释放内存
2. worker 服务：内存呈现周期性波动，7天内下降约7GB至15GB后突然释放到19GB左右

通过监控系统查询缓存指标发现，UncompressedCacheBytes 配置为可用内存的三分之一左右，但缓存使用情况显示可能存在异常。

问题定位

经过深入分析，发现问题主要与磁盘缓存机制有关：

1. 磁盘缓存文件堆积：在 /var/byconity/data/part_disk_cache/meta 目录下发现大量未被及时删除的文件，手动删除后服务内存立即得到释放
2. 写入节点缓存机制：写入节点(vw_write)本身不需要 DiskCache，但当前配置下仍然会进行缓存写入
3. 混合工作负载影响：写入节点同时执行大量 insert into select 操作，加剧了缓存压力

技术背景

ByConity 的磁盘缓存机制设计用于加速查询性能，但对于纯写入节点来说：

1. 写入节点特性：主要负责数据摄入，不直接服务查询请求
2. 缓存必要性：写入操作产生的缓存对后续查询无直接帮助
3. 资源消耗：缓存管理本身会占用内存和磁盘I/O资源

解决方案

1. 全局配置调整

对于写入专用虚拟仓库(vw_write)，建议关闭本地磁盘缓存：

merge_tree:
  enable_local_disk_cache: 0

配置生效需要重启对应 worker 服务。

2. 查询级优化

对于在写入节点执行的 insert into select 语句，可通过添加设置参数临时规避：

INSERT INTO table SELECT ... SETTINGS disk_cache_mode = 'SKIP_DISK_CACHE'

这种方式可以避免特定查询对缓存的读写，同时不影响其他虚拟仓库的缓存机制。

3. 缓存参数调优

通过调整以下参数控制缓存大小：

disk_cache_strategies:
  simple:
    lru_max_size: 78935838720  # 最大缓存大小(字节)
    lru_max_object_num: 100000 # 最大缓存对象数量

需要注意这些参数的实际效果可能受工作负载特性影响。

实施建议

1. 分阶段实施：建议先在测试环境验证配置变更效果
2. 监控调整：实施后密切监控内存和查询性能指标
3. 工作负载分离：长期考虑将写入和查询工作负载完全分离到不同的虚拟仓库
4. 版本升级：关注后续版本对缓存管理的优化改进

总结

ByConity 的内存管理需要根据实际工作负载特性进行针对性调优。对于写入密集型节点，关闭不必要的磁盘缓存可以显著降低内存压力。同时，通过合理的参数配置和查询级优化，可以在保证系统稳定性的前提下优化资源利用率。建议用户结合自身业务特点，选择最适合的优化方案。