MongoDB清理system.sessions后磁盘空间不释放，是因为删除仅逻辑移除，WiredTiger不立即归还物理空间；且session关联的oplog条目、journal数据及MVCC旧版本仍被持有，而capped集合不支持compact，需通过杀长事务、缩短超时、推进oplog截断或调优cache等手段才能真正释放空间。

事务本身不直接占磁盘空间，但开启事务后未及时提交/回滚 + 长时间运行的Session（尤其是带大量写操作的）会持续持有oplog、journal和WiredTiger缓存中的旧版本数据，导致磁盘空间被快速撑满。

为什么清理 Session 记录后磁盘没释放

删除 system.sessions 集合里的文档（比如用 db.system.sessions.deleteMany({})）只是逻辑移除，WiredTiger 不会立刻归还物理空间给操作系统。你看到的 df -h 空间不变，是因为：

• system.sessions 是 capped collection，但 MongoDB 5.0+ 默认启用 enableMajorityReadConcern: true，这会让 session 数据同时写入 oplog 和 journal，放大空间占用
• session 文档删除后，其关联的 oplog 条目仍需保留直到所有节点同步完成（受 oplogSizeMB 和复制延迟影响）
• WiredTiger 的旧版本数据（用于 MVCC）在事务未彻底结束前无法回收，compact 对 system.sessions 无效（capped 集合不支持 compact）

真正有效的 Session 清理路径

别只盯着 system.sessions 删除——它只是表象。重点是切断源头并释放底层资源：

Remix V2 Meta Sessions Review

审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他

下载

• 停掉长期空闲的客户端连接：执行 db.currentOp({secs_running: {$gt: 3600}}) 找出运行超 1 小时的 op，用 db.killOp() 干掉它们（注意避免杀主事务）
• 检查并缩短 logicalSessionTimeoutMinutes：在 /etc/mongod.conf 中设为 30（默认 30，但有些老部署被改大），重启 mongod 生效
• 强制推进 oplog 截断：对副本集主节点运行 rs.stepDown() 触发一次主备切换，新主节点会基于最新同步点压缩 oplog
• 如果确认无活跃事务，可手动清理 journal：停止 mongod → 删除 /var/lib/mongodb/journal/ 下所有 *.wt 文件 → 启动（仅限单机或维护窗口内操作）

预防事务型 Session 占满磁盘的硬约束

靠事后清理永远被动。必须从配置层卡死资源上限：

• 在连接字符串里加 maxIdleTimeMS=60000 和 minPoolSize=1&maxPoolSize=50，防止应用端连接池堆积空闲 session
• 对使用事务的业务代码，严格限定 session.startTransaction({readConcern: {level: "local"}, writeConcern: {w: "majority"}})，禁用 readConcern: "snapshot"（它会锁住更久的快照版本）
• 监控关键指标：用 db.serverStatus().metrics.operation.fastmod 看未提交事务数；用 db.getSiblingDB("local").oplog.rs.stats().size 看 oplog 实际体积是否逼近 oplogSizeMB

最常被忽略的一点：WiredTiger cache 压力大会导致 journal 刷盘变慢，间接拖长旧版本数据存活时间。检查 db.serverStatus().hostInfo.system.memInfo 中 MemAvailable 是否低于 2GB —— 如果是，调低 storage.wiredTiger.engineConfig.cacheSizeGB 比盲目删 session 更治本。