Grist Core项目中MinIO客户端无限重试导致磁盘占满问题分析

问题背景

在Grist Core文档协作平台的自托管环境中，我们发现了一个与MinIO对象存储服务交互相关的资源泄漏问题。当文档工作节点(docWorker)与MinIO服务器之间的多部分上传被意外中断时，系统会进入无限重试循环，同时伴随着文件描述符泄漏和磁盘空间异常增长的现象。

问题现象

运维人员观察到以下典型症状：

1. MinIO服务重启后，正在进行的多部分上传(如文档快照)会被中断
2. docWorker日志中持续出现"multipart upload does not exist"错误信息
3. 系统监控显示磁盘使用量(df命令)持续增长，而实际存储目录(/persist)大小(du命令)保持稳定
4. 检查发现/proc/{node_pid}/fd中存在大量已删除但未释放的文件描述符
5. 只有重启docWorker才能终止这个异常状态

技术分析

根本原因

这个问题源于两个层面的缺陷：

1. 重试机制缺陷：当MinIO服务中断导致多部分上传失败时，Grist的docWorker没有设置合理的重试上限和回退策略，导致无限重试循环。

2. 资源管理缺陷：在重试过程中，Node.js进程未能正确关闭已经打开的文件描述符。虽然文件本身可能已被删除，但内核仍会为这些未释放的描述符保留磁盘空间。

影响范围

该问题主要影响：

• 使用MinIO作为存储后端的自托管Grist实例
• 进行大文件(如文档快照)上传的场景
• 存储服务不稳定的环境

技术细节

在多部分上传过程中，Grist会：

1. 打开本地文件并创建读取流
2. 初始化MinIO多部分上传会话
3. 分块上传文件内容
4. 完成上传会话

当MinIO服务在步骤2-4之间重启时，上传会话会失效，但Grist客户端仍会持有着原始文件的读取流。由于没有正确的错误处理和资源清理逻辑，这些流会一直保持打开状态。

解决方案

临时解决方案

对于遇到此问题的运维人员，可以：

1. 监控/proc/{node_pid}/fd目录中的文件描述符数量
2. 当发现异常增长时，重启受影响的docWorker服务
3. 考虑增加对MinIO服务稳定性的监控

长期解决方案

从技术架构角度，建议：

1. 实现合理的重试策略，包括：

   • 设置最大重试次数
   • 采用指数退避算法
   • 对不可恢复错误(如上传会话失效)进行特殊处理

2. 加强资源管理：

   • 确保所有文件流都有正确的关闭逻辑
   • 使用try-finally或资源管理包装器保证资源释放
   • 考虑实现文件描述符泄漏检测机制

3. 更新MinIO客户端库：

   • 使用最新版本的minio-js客户端(8.0.5+)，该版本已修复多个重试相关的问题

最佳实践建议

对于Grist自托管用户，建议：

1. 保持MinIO服务的稳定性，避免在业务高峰期进行维护
2. 对大文件上传实施监控和告警
3. 定期检查docWorker的资源使用情况
4. 考虑实现自动化机制来回收泄漏的资源
5. 及时更新到包含相关修复的Grist版本

总结

这个问题展示了分布式系统中资源管理和错误处理的重要性。通过改进重试策略和加强资源生命周期管理，可以显著提高系统的健壮性。对于自托管用户，理解这些底层机制有助于更好地运维Grist实例，确保服务稳定性。