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 更治本。
