XTDB项目中磁盘空间耗尽问题的分析与解决方案

问题背景

在XTDB数据库系统运行Auctionmark基准测试时，出现了java.io.IOException: No space left on device错误。该问题发生在24小时持续运行的测试环境中，每个节点配置了50GiB的持久卷声明(PVC)，并且设置了75%的最大磁盘缓存使用率(maxdiskcachepercentage)。

问题现象

系统日志显示，当磁盘空间耗尽时，会抛出以下异常堆栈：

java.util.concurrent.ExecutionException: clojure.lang.ExceptionInfo: Ingestion stopped: java.io.IOException: No space left on device

深入分析

初始假设验证

最初怀疑是磁盘缓存超过了配置的75%限制(37.5GiB)，但进一步调查发现实际使用情况更为复杂。

磁盘使用情况调查

通过监控数据发现：

1. 在100GiB PVC的测试环境中，磁盘缓存按预期维持在75GiB上限
2. 当前"使用中"字节数(包括固定字节和可回收字节)约为44GiB
3. 但df -h命令显示实际已使用59GiB

磁盘空间差异原因

检查磁盘缓存目录结构发现：

15G /var/lib/xtdb/buffers/disk-cache-1/.tmp
45G /var/lib/xtdb/buffers/disk-cache-1/tables

存在15GiB的临时文件(.tmp目录)，这些文件未被及时清理。在50GiB PVC的环境中，37.5GiB缓存加上15GiB临时文件确实会超过限制。

临时文件堆积机制

1. 文件上传流程：

   • 调用upload-arrow-file到对象存储
   • 写入文件通知到主题
   • 调用磁盘缓存的.put方法，执行原子性移动操作

2. 问题场景：

   • 当出现"Blob already exists"警告时(其他节点已上传相同文件)
   • 系统会中止多部分上传并抛出错误
   • 此时不会调用.put方法
   • 导致临时文件未被清理

解决方案

1. 确保在所有上传路径(包括失败情况)中都清理临时文件
2. 增加临时文件监控和自动清理机制
3. 考虑优化文件上传冲突处理逻辑

实施建议

1. 在文件上传错误处理流程中显式添加临时文件清理逻辑
2. 增加临时文件大小监控和告警
3. 对于频繁出现的文件冲突情况，优化节点间协调机制

总结

XTDB在长时间高负载运行中，由于临时文件清理机制不完善，可能导致磁盘空间耗尽。通过完善错误处理流程和增加临时文件管理机制，可以有效解决此类问题，提高系统稳定性。