【WiredTiger 内核】运维与排障：HS 膨胀、cache 压力与长游标
内容提要
本文介绍WiredTiger排障方法，强调禁止删除HS或日志文件、多实例写同一路径。按现象分类：HS增长查历史窗口与长事务；缓存压力查dirty与eviction；长游标拖住历史回收；日志堆积因备份游标泄漏；启停慢因RTS与HS体积。建议观测serverStatus、文件大小与应用慢查询，并记录版本与采样时间。
延伸解读
排障先定机制，再谈参数
本文强调排障应基于现象映射到机制，而非直接猜测参数。例如，HS 膨胀可能源于历史窗口过大、长事务或更新载荷大，需通过核对窗口值、活跃会话和更新速率来定位。这种机制导向的方法有助于避免盲目调整参数，提高排障效率。
禁止操作清单：避免常见误区
文章明确禁止手工删除或截断 WiredTigerHS.wt 和 WiredTigerLog.* 文件，以及多实例写同一 dbPath。这些操作可能导致数据损坏或引擎异常。运维人员应通过调整窗口、检查长事务和游标来解决问题，而非直接操作文件。
观测面与数据记录建议
建议从 MongoDB serverStatus、文件系统文件大小和应用慢查询三个层面观测。记录时需注明版本、采样时间和是否删减，以便复现和对比。这有助于建立可核对的口径，提升排障的准确性和可追溯性。
Q&A
WiredTiger 中 WiredTigerHS.wt 文件持续增长，可能的原因有哪些？
可能原因包括：历史窗口过大（minSnapshotHistoryWindowInSeconds 设置过长）、Oldest 推不动（存在长读、长游标或复制延迟）、更新载荷大（高频修改大文档）、HS 页回收慢（checkpoint 或 compaction 问题）。
WiredTiger 出现 cache 压力和延迟尖刺时，应该检查哪些指标？
应检查 dirty 占比、eviction 统计、checkpoint 前等待、updates_trigger 是否触发、大事务或长事务缓冲、HS 与用户页是否争抢 cache，以及 cacheSize 设置是否合理（过小导致频繁 reconcile，过大挤占文件系统缓存）。
长游标或长事务如何影响 WiredTiger 的历史回收？
长时间不提交的读或未关闭的游标会通过 pinned timestamp 拖住历史回收的下界，导致旧版本无法被清理，从而造成历史存储膨胀。
WiredTiger 日志文件堆积的可能原因是什么？
日志文件堆积通常是因为 backup cursor 或 log cursor 未关闭，导致自动删除机制停摆，checkpoint 无法推进。
WiredTiger 启动和停止极慢可能是什么原因？
可能原因是异常关机后恢复时执行 RTS（Rollback-to-Stable）和随后的 checkpoint，加上不稳定更新和 HS 体量大导致 I/O 高。
在 WiredTiger 排障中，有哪些操作是明确禁止的？
禁止手工删除或截断 WiredTigerHS.wt 文件；禁止在 backup cursor 或热备份窗口外乱删 WiredTigerLog.* 文件；禁止多实例写同一 dbPath。
WiredTiger 排障时建议观测哪些方面的数据？
建议观测：MongoDB 的 db.serverStatus() 中 wiredTiger 相关节（cache、reconciliation、transaction）、集合与 dbPath 文件大小；文件系统层面 WiredTigerHS.wt、WiredTigerLog.* 和各 .wt 文件大小的时间序列；应用层面慢查询、游标超时、写关注与 journal 间隔。
