GridFS写入不直接触发fsync，抖动源于WiredTiger的checkpoint刷盘策略；默认每60秒强制刷脏页，脏页超80%或journal与数据共盘会加剧IO毛刺；需通过mongostat flushes、serverStatus cache和transaction指标定位，并调优cache大小、checkpoint周期及IO隔离。
GridFS写入本身不直接触发fsync，抖动来自WiredTiger引擎的刷盘策略
GridFS没有自己的磁盘刷写逻辑，它只是把分块后的fs.chunks文档和元数据fs.files文档交给MongoDB写入。真正决定何时落盘的是WiredTiger存储引擎——它按自身配置的检查点（checkpoint）周期和脏页比例来批量刷盘，不是每条insert都fsync。
常见错误现象：压测时iostat -x 1看到await尖刺、%util周期性冲高、write吞吐呈波浪形，但mongostat里insert平稳——这说明瓶颈不在应用层写入速率，而在WiredTiger后台线程集中刷脏页。
- WiredTiger默认每60秒做一次checkpoint，期间会强制刷所有脏页到磁盘，造成IO毛刺
- 若并发写入持续推高cache中脏页比例（默认阈值80%），引擎会提前触发刷盘，加剧抖动频率
-
storage.wiredTiger.engineConfig.journalDir和数据文件共用同一块物理盘时，journal日志写入与checkpoint刷盘会争抢IO带宽
如何确认是WiredTiger checkpoint导致的抖动
别猜，用mongostat和serverStatus交叉验证：
- 运行
mongostat --host localhost:27017 -n 1，盯住netIn和flushes两列：如果flushes每60秒突增1次，且与IO毛刺时间完全对齐，基本锁定checkpoint - 执行
db.runCommand({ serverStatus: 1 }).wiredTiger.cache，重点看"bytes currently in the cache"和"maximum bytes configured"比值，若长期＞75%，说明脏页压力大 - 查
db.serverStatus().wiredTiger.transaction里的"update conflicts"，若该值在抖动时段同步上升，说明写入竞争加剧了page fault和刷盘延迟
调整checkpoint间隔和cache大小能缓解但不能根治
WiredTiger的刷盘行为无法关闭，只能调参数平滑其冲击：
- 加大cache：启动时加
--wiredTigerCacheSizeGB 4（根据物理内存设为50–60%），降低脏页占比触发提前刷盘的概率 - 拉长checkpoint周期：在
mongod.conf里配storage.wiredTiger.engineConfig.checkpointDelaySecs: 300（最长300秒），减少刷盘频次 - 禁止journal与data混盘：用
storage.journal.enabled: true+storage.wiredTiger.engineConfig.journalDir: "/ssd/journal"，把journal单独挂到NVMe盘上 - 禁用
storage.syncPeriodSecs（已废弃），这个旧参数对WiredTiger无效，设了也没用
真正要盯住的是chunk写入模式，而非fsync本身
用户常误以为“写得快就刷得多”，其实更关键的是fs.chunks文档的写入密度和局部性：
- chunkSizeBytes太小（如设成8KB）→ 单文件生成上千文档 → 索引B+树频繁分裂 → cache miss飙升 → 更多page fault → 更多刷盘
- 没建
{ files_id: 1, n: 1 }索引 → 写fs.chunks前要scan查是否存在重复块 → 拉长事务时间 → 脏页驻留更久 → 加重刷盘压力 - 复用
MongoClient但未控制并发流数 → 瞬间几百个createWriteStream→ WiredTiger write queue堆积 → 触发激进刷盘保稳定性
磁盘抖动的根因从来不在fsync开关，而在你是否让WiredTiger的缓存、索引、并发三者之间保持平衡。一旦其中一环失衡，刷盘就会从“后台安静工作”变成“前台暴力清场”。
