RocksDB中SST文件泄漏问题的分析与解决

问题背景

在使用RocksDB 7.4.4作为Java应用程序的嵌入式数据库时，发现了一个SST文件泄漏的问题。这些文件在磁盘上成为"孤儿文件"，只有在服务重启时才会被清理。这个问题特别出现在以下场景中：

1. 在某个列族(Column Family)上持续存在40-80次/秒的活跃seek迭代器操作
2. SST文件创建时间与服务启动时间的小时边界偏移相关
3. 这些文件在特定时间点被压缩操作消费
4. 检查点操作显示这些文件被硬链接
5. 压缩后没有相应的文件删除日志记录
6. 后续检查点中这些文件不再被引用
7. 服务重启时这些文件才被清理

深入分析

通过详细分析日志和监控指标，我们发现这些"孤儿"SST文件与迭代器的生命周期管理密切相关。具体表现为：

1. 迭代器使用模式：应用程序创建了大量seek迭代器，每个迭代器都关联一个快照，并在操作完成后(无论是否发生异常)立即释放。99.999%的查询生命周期短于1秒，少数不超过30秒。

2. 时间相关性：文件泄漏现象与小时边界时间点高度相关，这表明可能与定时任务或批处理操作有关。

3. 压缩行为：这些文件被压缩操作消费后，理论上应该被删除，但删除事件没有记录在日志中。

4. 版本控制：通过监控NUM_LIVE_VERSIONS指标，可以观察到RocksDB内部版本控制的变化与文件泄漏时间点吻合。

根本原因

经过深入调查，发现问题根源在于迭代器没有正确关闭。虽然应用程序代码看起来会在操作后释放迭代器，但实际上存在一些遗留代码路径没有正确处理异常情况，导致迭代器泄漏。

在RocksDB中，每个迭代器都会持有一个版本引用。当迭代器没有正确关闭时，这些版本引用会阻止相关SST文件被删除，即使这些文件已经被压缩操作消费且不再属于当前版本。

诊断工具

在诊断过程中，以下几个关键指标特别有用：

1. LIVE_SST_FILES_SIZE：显示当前活跃的SST文件总大小
2. TOTAL_SST_FILES_SIZE：显示所有SST文件的总大小
3. NUM_LIVE_VERSIONS：显示当前活跃的版本数量
4. NO_ITERATOR_CREATED：记录创建的迭代器数量
5. NO_ITERATOR_DELETED：记录删除的迭代器数量

通过比较这些指标，特别是LIVE_SST_FILES_SIZE与TOTAL_SST_FILES_SIZE的差异，以及NO_ITERATOR_CREATED与NO_ITERATOR_DELETED的差值，可以准确识别出文件泄漏的时间窗口和严重程度。

解决方案

解决这个问题的关键在于确保所有代码路径都正确关闭迭代器。具体措施包括：

1. 资源管理：使用try-with-resources模式确保迭代器总是被关闭
2. 异常处理：在所有异常处理路径中都包含迭代器关闭逻辑
3. 代码审查：检查所有创建迭代器的代码路径
4. 监控增强：持续监控迭代器创建/删除比例和版本数量

经验总结

这个案例提供了几个重要的经验教训：

1. 资源生命周期管理：在嵌入式数据库使用中，必须严格管理所有资源(迭代器、快照等)的生命周期。

2. 监控指标的价值：RocksDB提供的丰富监控指标是诊断问题的有力工具，应该充分利用。

3. 时间模式分析：当问题表现出时间相关性时，应该检查相应时间点的系统活动和配置。

4. 版本控制影响：理解RocksDB的版本控制机制对于诊断存储相关问题至关重要。

通过这次问题的解决，我们不仅修复了文件泄漏问题，还建立了更完善的资源管理和监控机制，为系统的长期稳定运行奠定了基础。