Pika数据库内存泄漏问题分析与优化实践

问题现象

某用户在使用Pika 3.3.6版本时遇到了一个奇怪的内存问题。服务器配置为8核16G内存和1T SSD存储，实例数据量约100G，客户端连接数约100个。监控显示内存使用率并不高，但进程内存持续增长，最终导致OOM（内存不足）kill。

问题分析

通过分析，我们发现Pika的内存使用主要由以下几个部分组成：

1. Memtable内存：默认配置下最大可达10G
2. Block Cache：用于缓存数据块
3. Table Cache：存储SST文件的索引和过滤器信息

在用户案例中，Table Cache占用了约8G内存，这对于16G内存的服务器来说已经相当可观。Table Cache默认没有硬性上限，仅受max-cache-files参数限制（默认5000），这很容易成为OOM的诱因。

根本原因

问题的核心在于：

1. Table Cache缺乏有效的内存限制机制
2. 频繁的写入操作和Compaction过程会不断打开更多SST文件，导致Table Cache持续增长
3. 默认配置下，Table Cache与Block Cache是分开管理的

解决方案

经过技术团队分析，建议采取以下优化措施：

1. 启用cache-index-and-filter-blocks选项：

   • 将Table Cache纳入Block Cache统一管理
   • 通过Block Cache的上限来控制整体内存使用

2. 调整Block Cache大小：

   • 初始建议设置为5G
   • 根据实际使用情况逐步调整

3. 限制Memtable大小：

   • 默认10G的max-write-buffer-size对于16G内存的服务器过大
   • 建议调整为1-2G

4. 优化Compaction策略：

   • 避免在业务高峰期执行Compaction
   • 合理设置Compaction时间窗口

实施效果

在测试环境中，将Block Cache设置为18G（32G内存服务器）后，虽然内存波动仍然存在，但整体稳定性有所提升。建议持续监控并根据实际负载情况进一步优化参数配置。

最佳实践建议

1. 对于生产环境，建议：

   • 监控Table Cache和Block Cache的实际使用情况
   • 根据业务负载特点调整内存分配比例

2. 对于写入密集型场景：

   • 适当减小Memtable大小
   • 增加Block Cache比例

3. 对于读取密集型场景：

   • 可以增大Block Cache
   • 但需确保总内存使用不超过物理限制

通过合理的参数配置和持续的监控优化，可以有效避免Pika数据库的OOM问题，保证服务的稳定运行。