gridfs写入tb级数据时maxpoolsize被耗尽，主因是openuploadstream()独占连接至上传完成且错误时未destroy()导致泄漏；须用p-limit限并发（3～5）、显式destroy()、上传前校验socket、按uploadid精准清理脏数据，并将chunksizebytes设为4mb以减少chunk数量和元数据锁竞争。
GridFS写入TB级数据时maxPoolSize为什么总被耗尽
不是连接池太小，而是每个 openUploadStream() 实际会独占一个连接直到上传完成，而TB级文件上传往往持续数分钟甚至更久。期间这个连接无法归还池中，QPS稍高就直接卡死。更麻烦的是，如果上传中途出错（如网络抖动、客户端断连），流没被 destroy()，连接就永久泄漏。
必须用p-limit控制并发上传流数量
盲目调大 maxPoolSize 只会让问题更隐蔽——比如从100拉到500，表面上不报错，但后端 mongos 或分片节点的连接数可能翻倍打满，引发雪崩。真实有效的做法是主动限流：
- 用
p-limit包裹所有openUploadStream()调用，建议上限设为3～5（尤其当上传来自前端分片请求时） - 每个流必须显式监听
error事件并调用stream.destroy()，否则错误残留会持续占连接 - 上传前检查
req.socket.destroyed，若已断开立即放弃并destroy()流
上传中断后如何清理脏数据
TB级上传一旦中断，fs.chunks 里会留下大量孤儿 chunk，下次同名重传时可能因元数据未清理而冲突或重复写入。关键动作不是“重试”，而是“精准清理”：
- 上传前生成唯一
uploadId（如 UUID v4），作为metadata.uploadId写入 - 中断后执行
gridfs_bucket.delete({ "metadata.uploadId": "xxx" })，它会自动删掉对应fs.files和所有关联fs.chunks - 不要依赖
files_id查询清理，因为uploadId是业务层可控标识，比 ObjectId 更可靠
chunkSizeBytes设多大才不影响吞吐又不压垮连接池
默认 255KB 在 TB 级场景下会产生海量 chunk 文档，加剧元数据锁竞争和 journal 刷盘压力，间接拖慢事务提交速度，进一步延长连接占用时间。实测有效配置是：
-
chunkSizeBytes: 4 * 1024 * 1024（4MB）：chunk 数量减少约 16 倍，显著降低fs.chunks插入频率 - 配合
storage.wiredTiger.collectionConfig.blockCompressor: "zstd"减少写入字节数，缓解 journal I/O - 注意：chunkSize 改变后，旧文件无法用新参数读取，需统一升级客户端逻辑
真正卡住连接池的，往往不是单次上传慢，而是上传流没被及时销毁、中断后脏数据堆积、以及 chunk 粒度过细导致元数据锁争抢——这三处漏掉任一，调再大的 maxPoolSize 都只是把崩溃延迟几秒而已。
