StatefulSet的VolumeClaimTemplates必须显式指定storageClassName，否则会fallback到默认类（如hostPath或local卷），导致GridFS并发读写卡顿；需硬编码为cephfs-sc、ebs-sc等经验证的高性能存储类，并通过kubectl get pv,pvc确认绑定正确。
StatefulSet 的 VolumeClaimTemplates 必须显式指定 storageClassName
很多人直接用默认 StorageClass，结果发现 GridFS 上传卡顿、下载延迟高。问题往往出在底层 PV 类型：默认类可能绑定的是 hostPath 或 local 卷，它们不支持多 Pod 并发读写，而 GridFS 在多个应用 Pod 同时调用 open_download_stream 或 upload_from_stream 时，会因锁竞争或挂载冲突导致阻塞。
必须在 VolumeClaimTemplates 中硬编码 storageClassName，指向你确认过性能达标的后端，比如：cephfs-sc（CephFS）、ebs-sc（AWS EBS gp3）、azure-disk-sc（Premium_LRS）。漏掉这行，Kubernetes 就会 fallback 到默认类，且不会报错——但你会在 kubectl get pvc 里看到 PVC 处于 Pending 状态，或绑定到了错误的 PV。
- 检查命令：
kubectl get pv,pvc -n mongodb，确认 PVC 的STORAGECLASS列与预期一致 - 验证 PV 是否真被 mongod 进程使用：
kubectl exec -it mongod-0 -n mongodb -- ls -l /data/db，输出应显示挂载点来自对应 PV 的设备路径 - 如果用 NFS，务必确认服务端配置了
noatime,nodiratime,async，客户端挂载参数含nfsvers=4.1,hard,intr
GridFS chunkSize 不要盲目调大，128KB ~ 255KB 是生产推荐区间
chunkSize 直接影响 WiredTiger 引擎的 I/O 模式。设成 1MB 看似减少 chunk 数量，实则放大单次 write lock 时间，尤其在并发上传场景下，容易触发 WT_ROLLBACK 错误或副本集心跳超时；设得太小（如 16KB），又会导致 fs.chunks 集合文档爆炸，索引膨胀、查询变慢。
PyMongo 默认是 255KB，Node.js 驱动也是这个值，Java 驱动默认 256KB——保持默认通常最稳。只有当你明确观察到大量小文件（fs.chunks 文档数超过千万级时，才考虑降到 128KB，并同步补上复合索引：
db.fs.chunks.createIndex({ "files_id": 1, "n": 1 }, { unique: true })
- 不要用
mongofiles工具上传时加--chunkSize参数覆盖全局设置，它只影响本次命令，对驱动层无效 - 修改
chunkSize必须在首次上传前定死，已有文件不会自动重分块；迁移需用mongorestore+ 导出/导入 - 监控关键指标：
db.fs.chunks.countDocuments()和db.fs.files.countDocuments()的比值，理想在 20~50 之间
NFS 用于 GridFS 时，WiredTiger 日志刷盘会成为瓶颈
WiredTiger 默认每 100ms 刷一次 .wt 日志，NFS 的 sync 延迟会让这个动作卡住，表现为 mongod 日志反复出现 waiting for journal to recover，或者副本集成员频繁 STARTUP2 → RECOVERING 循环。
这不是 GridFS 本身的问题，而是 NFS + 数据库引擎的组合缺陷。即使你把 chunkSize 调优得再好，只要底层存储无法低延迟响应随机小写，GridFS 的吞吐就上不去。
- 临时缓解：在 mongod 启动参数里加
--wiredTigerEngineConfigString="log=(prealloc=false)"，减少日志预分配开销（仅限测试） - 真正解法：换 CephFS 或云厂商 CSI 驱动；若必须用 NFS，请确保服务端用 XFS 文件系统、客户端 mount 时加
actimeo=1 - 验证是否生效：
kubectl exec mongod-0 -n mongodb -- iostat -x 1 3，关注await和%util，>20ms 或 >90% 就说明 I/O 卡住了
mongo-express 的 GridFS 界面上传不是“直传”，会吃光 Pod 内存
如果你用 mongo-express Web 界面上传大文件（>50MB），它的实现是先将整个文件读进 Node.js 进程内存，再通过驱动调用 upload_from_stream。这意味着一个 200MB 的 PDF 会瞬间占用 mongo-express Pod 至少 250MB 内存——而默认资源限制常设为 memory: 128Mi，直接 OOMKill。
这不是 bug，是设计使然。生产环境绝不能依赖它做批量上传。
- 正确做法：让业务服务直连 MongoDB，用对应语言驱动（PyMongo/Node.js MongoDB Driver）流式上传
- 若必须用 Web 界面管理，给 mongo-express Pod 单独提额：
resources.limits.memory: 1Gi，并加readinessProbe防止流量打进来时还没 ready - 注意：
mongo-express的 GridFS 下载是流式响应，不占内存，这点比上传安全得多
GridFS 性能瓶颈从来不在 MongoDB 层面，而在 PV 类型选择、I/O 路径配置和客户端使用方式这三个地方。最容易被忽略的是：你以为改了 chunkSize 就能提速，其实如果 PV 不支持低延迟随机写，所有调优都是隔靴搔痒。
