调高wiredtigerconcurrentread/writetransactions需谨慎：先确认是否真卡在wiredtiger层，再排查慢查询、队列积压；仅当cpu利用率长期低于70%且iowait低时才考虑调大。
别急着调高 wiredTigerConcurrentReadTransactions 和 wiredTigerConcurrentWriteTransactions —— 大多数情况下，它们耗尽是结果，不是原因。
看到 available: 0 就说明 tickets 不够用了？
不一定。先查清楚是不是真卡在 WiredTiger 层：
- 运行
db.serverStatus().wiredTiger.concurrentTransactions，确认read.available或write.available确实为 0 - 再看
db.currentOp({secs_running: {$gt: 5}})，有没有长时间运行的查询（比如没走索引的全表扫描） - 检查
mongostat输出里的qr/qw（读/写队列长度）是否持续偏高；如果qr高但read.available没耗尽，说明瓶颈不在 WT ticket，而在网络、客户端连接池或查询本身 - 注意 MongoDB 7.0+ 中这两个参数默认可能显示为 0，因为已启用动态算法，实际值需看
totalTickets字段
什么时候可以安全调大 ticket 数？
只有满足以下全部条件时才考虑调大：
- CPU 利用率长期低于 70%（核数 × 70%），说明不是 CPU 瓶颈
- I/O 等待（
iowait）不高，磁盘响应正常（平均延迟 - 慢查询已优化：所有高频查询都有合适索引，
explain("executionStats")显示nReturned≈totalDocsExamined - cache_used 长期 ≤ 80%，eviction 压力小（
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]/cache_size） - 调整后必须监控上下文切换：
vmstat 1中cs（context switch）值不应突增 2× 以上
怎么动态修改，又不踩坑？
直接用 adminCommand 修改，无需重启，但要注意顺序和验证：
- 先调读票：
db.adminCommand({ setParameter: 1, wiredTigerConcurrentReadTransactions: 256 }) - 观察 5 分钟，确认
read.out上升但read.available不归零，且qr下降 - 再调写票：
db.adminCommand({ setParameter: 1, wiredTigerConcurrentWriteTransactions: 192 })（写票一般不建议超过读票） - 改完立刻查：
db.runCommand({ getParameter: 1, wiredTigerConcurrentReadTransactions: 1 })，确认返回值已更新 - 避免设过大：超过物理 CPU 核数 × 4 容易引发调度开销，例如 32 核机器，写票设到 256 就已偏高
MongoDB 7.0 的动态 tickets 到底怎么理解？
7.0+ 不再硬编码固定值，而是根据负载自动伸缩，但有两个关键事实容易被忽略：
-
wiredTigerConcurrentReadTransactions和wiredTigerConcurrentWriteTransactions返回值可能为 0，这不是错误，而是表示“由系统托管”——真实限制看db.serverStatus().wiredTiger.concurrentTransactions.read.totalTickets - 动态算法会参考
cache_used、eviction压力、I/O 延迟等指标，如果这些指标异常，它反而会主动收缩totalTickets来保稳 - 这意味着你不能只盯着 ticket 数，而要同步盯紧
eviction=(threads_min=1,threads_max=8)是否足够，否则动态 ticket 会被 eviction 拖累而不敢放开
