SubQuery项目临时文件膨胀问题分析与解决方案

问题背景

在使用SubQuery项目时，特别是当项目通过CID(内容标识符)部署时，系统会在运行过程中产生大量临时文件。这些文件会积累在系统的/tmp目录下，一周内可能增长到70GB以上，导致存储空间被快速耗尽。

问题根源

该问题的核心原因在于SubQuery项目的工作机制：

1. CID部署特性：当项目使用CID部署时，每次启动都需要从IPFS网络重新下载完整的部署文件包。这些下载的文件默认会存储在系统的临时目录中。

2. 容器自动重启机制：如果项目运行在Docker容器中，并且配置了自动重启(auto-restart)功能，当项目遇到问题或达到目标区块高度时，容器会自动重启。每次重启都会触发新一轮的文件下载。

3. 临时文件清理缺失：系统缺乏有效的临时文件清理机制，导致这些下载的文件不断累积而不会被自动清除。

技术细节

在SubQuery的架构设计中，使用CID部署是一种常见的做法，它允许项目通过IPFS网络进行分布式存储和版本控制。然而，这种设计在以下场景会产生问题：

• 开发环境频繁重启
• 项目达到预定区块高度后自动重启
• 容器因各种原因崩溃后自动恢复

每次重新启动都会在/tmp目录下创建新的临时文件，而旧文件不会被自动清理。

解决方案

针对这一问题，可以采取以下几种解决方案：

1. 使用本地项目部署： 避免使用CID部署方式，改为将项目文件直接挂载到容器中。这样可以避免重复下载带来的临时文件问题。

2. 配置临时文件清理： 在Docker容器中配置定期清理/tmp目录的脚本，或者在项目启动脚本中加入清理旧临时文件的逻辑。

3. 修改存储路径： 通过环境变量或配置参数，将临时文件存储路径指向具有更大空间的分区，或者配置为使用内存文件系统(tmpfs)。

4. 优化重启策略： 对于不需要频繁重启的项目，可以调整Docker的重启策略，避免不必要的重启操作。

最佳实践建议

对于长期运行的SubQuery项目，建议采用以下实践：

1. 生产环境优先考虑使用本地项目部署而非CID部署
2. 为Docker容器配置合理的资源限制和重启策略
3. 实现定期清理临时文件的维护脚本
4. 监控/tmp目录的大小，设置告警阈值

总结

SubQuery项目在使用CID部署方式时产生的临时文件积累问题，虽然不会影响核心功能，但会对系统存储空间造成压力。通过理解其工作机制并采取适当的配置调整和清理策略，可以有效解决这一问题，确保项目长期稳定运行。