1. 项目背景业务场景本地生活电商准备迎接年度最大促销——“618 年中大促”。运维团队接到死命令系统必须扛住 10 万 QPS 的读写混合负载P99 延迟 100ms。目前的架构——3 分片 × 3 节点复制集8 核 32GB × 9 台服务器。压测结果显示——当前配置在 3 万 QPS 时 P99 延迟已经到 300ms距离目标还有 3 倍差距。容量规划上也有盲区——运维不知道现有的磁盘能支撑多久日均增量 50GB磁盘剩余 1TB——大约 20 天就会满但还没有扩容预算内存的工作集到底多大也不清楚现在是 32GB但 WiredTiger 缓存配置了 16GB——够不够CPU 瓶颈到底是在 MongoDB Server 层还是 WiredTiger 层还是网络层。痛点性能调优没有银弹。NUMA 架构可能导致 MongoDB 只用到一半内存透明大页Transparent Huge Pages可能让 WiredTiger 的 4KB 页碎成渣文件系统选择ext4 vs xfs影响fsync性能磁盘 IOPS 不够导致 Checkpoint 期间的写入毛刺连接池、网络、内核参数……每一个环节都可能成为瓶颈。2. 项目设计小胖盯着压测报告上 P99 300ms 的红线大师我们 9 台服务器配了最强的 SSD、64 核 CPU、256GB 内存结果 3 万 QPS 就 P99 300ms这不科学大师性能调优第一步——不猜用数据说话。把压测期间的 MongoDB 指标拉出来我帮你定位瓶颈在哪一层。小胖我看过了CPU 85%IOPS 15000内存用了 90%连接池也没满……感觉全满了大师全满等于没有重点。我们按USE 方法论——逐一检查 Utilization利用率、Saturation饱和度、Errors错误数定位瓶颈的精确位置。CPU85% 是整体利用率但 MongoDB 是单进程的——如果是在 64 核机上只用了 8 核其他核空闲那整体 85% 其实意味着那 8 核已经满载了。用mpstat看每核利用率。IOPS15000 IOPS 看起来高——但对比你的 SSD 的标称能力假设 50000 IOPS还有余地。问题可能是 Checkpoint 期间的 IO 尖峰导致的抖动而不是平均 IOPS。内存90% 用在哪如果 WiredTiger 缓存只有 16GB而工作集是 50GB缓存淘汰频繁导致额外的磁盘 IO——这才是真正的瓶颈。技术映射USE 方法论——CPU 看每核利用率内存看缓存命中率和 eviction磁盘看 IOPS 的分布平均 vs P99网络看带宽和重传率。小胖那怎么找到工作集大小大师工作集大小 活跃查询中频繁访问的数据和索引的总和。估算方法——在高峰期运行db.serverStatus().wiredTiger.cache查看缓存使用率。如果 16GB 缓存中有 14GB 在被频繁访问且 eviction 0——说明工作集 16GB缓存不够。实际工作集 缓存当前使用量 因淘汰而额外产生的磁盘读对应的数据量。技术映射工作集 ≈ 缓存大小 × (1 eviction_io读 / 缓存命中)。如果缓存命中率 95%说明工作集显著大于缓存。小白容量规划怎么做磁盘、内存、CPU 各留多少余量大师一张表说清楚三者的规划资源规划公式警戒线磁盘(当前数据大小 日均增量 × 保留天数) × 1.5索引碎片使用率 70% 开始扩容内存工作集大小 × 1.2 2GB系统开销WiredTiger 缓存命中 95% 或 eviction 0CPU(目标 QPS × 查询平均 CPU 时间) × 1.3单核利用率 80% 或整体 CPU 70%小胖那系统调优呢我听人说 NUMA、透明大页、文件系统这些都要调大师对。快速清单NUMAnumactl --interleaveall mongod——防止 MongoDB 被限制在单 NUMA 节点上只能用一半内存。透明大页echo never /sys/kernel/mm/transparent_hugepage/enabled——WiredTiger 的 4KB 页和 2MB 大页冲突。文件系统XFS 比 ext4 更适合高并发小 IO——WiredTiger 大量 4KB 页读写更匹配 XFS 的 allocator。readaheadWiredTiger 有自己的预读逻辑——操作系统层的 readahead 反而干扰了——设为 8-16KB而非默认的 128KB。ulimit文件描述符ulimit -n 64000进程数ulimit -u 64000。swappinessvm.swappiness 1——尽量不使用 swap避免 WiredTiger 缓存被换出。大师总结今天记住——性能调优三步走USE 方法找瓶颈系统参数做基线NUMA/THP/XFS容量规划留余量30% 磁盘 20% CPU 缓存命中 95%。最后别忘了——压测后和压测中都要监控所有指标单靠压测报告的数字是片面的。3. 项目实战3.1 环境准备需要 Linux 服务器环境用于系统级调优。Docker 容器内部分参数NUMA/THP受宿主机控制。3.2 分步实现步骤一系统级性能基线检查# 内核参数检查清单 # 1. 透明大页状态cat/sys/kernel/mm/transparent_hugepage/enabled# 期望: [never] 或 always madvise [never] —— never 最前面表示当前禁用# 禁用命令: echo never /sys/kernel/mm/transparent_hugepage/enabled# 2. 内存交换倾向sysctlvm.swappiness# 期望: 1尽量不用 swap# 3. 文件描述符限制ulimit-n# 期望: 64000# 4. 磁盘 I/O 调度器SSD 推荐 noop 或 nonecat/sys/block/sda/queue/scheduler# 对 NVMe SSD: [none] 多队列无调度# 5. 文件系统预读blockdev--getra/dev/sda# 期望: 8-16KB——WiredTiger 有自己的预读逻辑# 6. NUMA 状态numactl--hardware# 如果有多 NUMA 节点——mongod 启动时用 numactl --interleaveall 绑定步骤二工作集与缓存命中率诊断// working-set-diagnose.js —— 工作集诊断use adminvarsdb.serverStatus()varcaches.wiredTiger.cachevarcacheUsedMBcache[bytes currently in the cache]/1024/1024varcacheMaxMBcache[maximum bytes configured]/1024/1024vardirtyMB(cache[tracked dirty bytes in the cache]||0)/1024/1024varpagesReadcache[pages read into cache]||0varpagesEvicted(cache[pages evicted by eviction server]||0)(cache[pages evicted by application threads]||0)print( 工作集诊断 )print(缓存使用:,cacheUsedMB.toFixed(0),MB /,cacheMaxMB.toFixed(0),MB,(,(cacheUsedMB/cacheMaxMB*100).toFixed(1),%))print(脏页:,dirtyMB.toFixed(0),MB)print(页读入:,pagesRead)print(页淘汰:,pagesEvicted)// 粗略的缓存命中率估计vartotalPageAccesspagesReadcache[pages requested from the cache]varhitRatetotalPageAccess0?(1-pagesRead/totalPageAccess)*100:nullif(hitRate!null){print(缓存命中率:,hitRate.toFixed(1),%,hitRate95?PASS:⚠ 建议增大缓存)}// 工作集估算// 如果 eviction 0 且频繁——说明工作集 当前缓存if(cache[pages evicted by application threads]0){print(⚠ 应用线程被迫淘汰——缓存严重不足)print( 建议 cacheSizeGB 至少增加到当前使用量的 1.5 倍)}步骤三容量规划计算器// capacity-planning.js —— 容量规划计算varsdb.serverStatus()vardbStatsdb.getSiblingDB(local_life).stats()// 输入参数运维填写vargrowthRatePerDay50// GB/天varretentionDays90// 保留天数vartargetQP100000// 目标 QPSvaravgQueryTimeMs2// 平均查询耗时// 1. 磁盘规划varcurrentSizeGBdbStats.dataSize/1024/1024/1024varindexSizeGBdbStats.indexSize/1024/1024/1024vartotalCurrentGBcurrentSizeGBindexSizeGBvarprojectedSizeGBtotalCurrentGBgrowthRatePerDay*retentionDaysvarsafetyMarginGBprojectedSizeGB*0.3// 30% 安全余量print( 容量规划 )print(当前数据:,currentSizeGB.toFixed(1),GB 索引:,indexSizeGB.toFixed(1),GB)print(,retentionDays,天后预计:,projectedSizeGB.toFixed(0),GB)print(建议磁盘:,(projectedSizeGBsafetyMarginGB).toFixed(0),GB)// 2. 内存规划varcacheSizeGBcache[maximum bytes configured]/1024/1024/1024varrecommendedCache(cacheUsedMB/1024)*1.5// 当前使用的 1.5 倍print(\n当前缓存:,cacheSizeGB.toFixed(1),GB, 建议:,recommendedCache.toFixed(1),GB)// 3. CPU 规划varestimatedCpuPerQueryavgQueryTimeMs/1000// 秒varrequiredCpuSectargetQP*estimatedCpuPerQueryvarrequiredCoresMath.ceil(requiredCpuSec*1.3)// 30% 余量print(\n目标 QPS:,targetQP,→ 需要约,requiredCores,个 CPU 核心)步骤四磁盘 IOPS 与 Checkpoint 毛刺诊断// iops-check.js —— 磁盘 IO 与 Checkpoint 监控// 在 mongosh 中每 2 秒采样一次 IO 相关指标functionsampleIO(){varsdb.serverStatus()varwts.wiredTigerreturn{time:newDate(),reads:wt[block-manager][blocks read]||0,writes:wt[block-manager][blocks written]||0,checkpointMs:wt.checkpoint?.[most recent time msecs]||0,evictionApp:wt.cache[pages evicted by application threads]||0}}varbeforesampleIO()sleep(5000)varaftersampleIO()varblocksReadafter.reads-before.readsvarblocksWrittenafter.writes-before.writesvariops(blocksReadblocksWritten)/5// 5 秒间隔 → 每秒 IOPSprint( IOPS 采样 (5秒) )print(读块:,blocksRead,写块:,blocksWritten)print(估算 IOPS:,iops.toFixed(0))print(最近 Checkpoint 耗时:,after.checkpointMs,ms)print(应用线程淘汰:,after.evictionApp-before.evictionApp)// 如果 Checkpoint 1000ms1秒——说明脏页过多checkpoint 期间 IO 风暴// 如果 evictionApp 在 5 秒内新增 0——缓存不够应用被迫参与淘汰步骤五mongostat mongotop 实时监控# mongostat 实时指标 # 每秒刷新一次输出 QPS、连接数、内存、锁等关键指标mongostat--urimongodb://admin:passhost:27017/?authSourceadmin-n301# 关键列解读# insert/query/update/delete: 每秒操作数# vsize/res: 虚拟内存/物理内存# qr/qw: 读/写队列长度 0 说明请求在等待# ar/aw: 活跃读/写连接数# netIn/netOut: 网络流量# conn: 连接数# dirty: 脏页百分比# used: 缓存使用率# mongotop 集合级读写负载 mongotop--urimongodb://admin:passhost:27017/?authSourceadmin5# 每 5 秒刷新一次显示每个集合的读写时间占比# 找出最忙的集合——读写时间最高的那个 → 优化它的索引或分片步骤六火焰图定位 CPU 热点# perf 采集 30 秒调用栈并生成火焰图核心步骤# 1. 采集在生产环境低峰期进行sudoperf record-F99-p$(pgrep mongod)-g--sleep30# 2. 生成火焰图sudoperf script|./FlameGraph/stackcollapse-perf.plmongod.folded ./FlameGraph/flamegraph.pl mongod.foldedmongod_flamegraph.svg# 3. 分析火焰图中的主要 CPU 消耗# 常见热点# - __wt_btree_insert → 索引写入热点 → 考虑批量写入或分片# - __wt_row_search → B-Tree 查找 → 索引选择性差或缺少索引# - mongo::BSONObj::toString → BSON 序列化 → 文档过大或返回字段过多# - malloc/free → 频繁内存分配 → 文档碎片化或工作集不稳定3.3 完整代码清单文件用途mongodb-lab/tuning/kernel-check.sh内核参数基线检查mongodb-lab/tuning/working-set-diagnose.js工作集与缓存命中率诊断mongodb-lab/tuning/capacity-planning.js容量规划计算器mongodb-lab/tuning/iops-checkpoint.jsIOPS 与 Checkpoint 毛刺诊断mongodb-lab/tuning/mongostat-capture.shmongostat 捕获脚本3.4 测试验证use admin// 1. 验证系统指标可采集varsdb.serverStatus()print(WiredTiger:,s.wiredTiger?PASS:FAIL)print(连接:,s.connections?PASS:FAIL)// 2. 验证磁盘统计vardbStatsdb.getSiblingDB(local_life).stats()print(磁盘统计:,dbStats.dataSize0?PASS:FAIL)// 3. 验证 Checkpoint 信息varcpdb.serverStatus().wiredTiger.checkpointprint(Checkpoint:,cp?PASS:FAIL)// 4. 验证 mongostat 可用// 在宿主机命令行运行: mongostat --versionprint(\n 性能调优工具验证完成 )4. 项目总结4.1 性能调优速查清单层级调优项推荐值/操作内核透明大页禁用 (never)内核swappiness1内核readahead8-16KB文件系统XFS优于 ext4硬件NUMAnumactl --interleaveallMongoDBcacheSizeGB物理内存 × 50%-70%MongoDBOplog 大小24-48 小时写入量MongoDB连接池 maxPoolSize50-100按 QPS 调应用批量写入bulkWrite 替代逐条 insert应用原子更新$inc filter替代 read-then-write4.2 适用场景极端性能调优适用大促前的容量评估和压测调优。数据库迁移到新硬件后的参数复查。周期性性能衰退的根因分析碎片、缓存命中率下降。新业务上线前的工作集评估和资源申请。4.3 注意事项注意事项说明内核参数修改后需重启 mongodTHP、swappiness 等修改需要 mongod 重启才生效perf 采集有性能开销生产环境低峰期采集 30s不要长时间运行XFS 优于 ext4 但并非银弹ext4 在纯读场景下可能更快容量规划的数字是经验值根据实际压测数据调整余量——模型需要校准4.4 常见踩坑经验故障案例一NUMA 导致只用一半内存某 128GB 服务器上 MongoDB 设置了cacheSizeGB: 80但实际只用了 40GB一半。根因服务器是双路 NUMA 架构mongod 进程只在一个 NUMA 节点上分配了内存——另一个节点的 64GB 空闲。解决numactl --interleaveall mongod或在 systemd service 中配置CPUAffinity和MemoryPolicyinterleave。故障案例二Checkpoint 期间的磁盘 IO 风暴某 SSD 服务器的 MongoDB 每 60 秒出现一次 2-3 秒的写入毛刺——Checkpoint 期间脏页刷盘产生大量 IO。根因脏页比例过高30%一次性刷盘量大。解决缩短 Checkpoint 间隔到 30 秒checkpoint(wait30,log_size1GB)使脏页更频繁但更平缓地刷盘同时增大 WiredTiger 缓存以减少总脏页量。故障案例三压缩算法选 snappy 导致磁盘膨胀某团队用 snappy 做默认压缩半年后磁盘使用率超预期——数据量 800GBsnappy 压缩后还有 650GB压缩率不到 20%。改用 zstd 后降到 420GB——节省了 35% 的空间。代价是 CPU 升高 15%但磁盘成本节省远大于 CPU 成本。解决压缩算法要根据数据特征选——高重复度数据日志/JSON用 zstd 收益大二进制数据图片/文件压缩率极低时用 none。4.5 思考题如果 WiredTiger 缓存命中率是 99%——说明缓存基本够用。但 P99 延迟仍然很高——可能的原因是什么提示不只看缓存命中还要看锁、网络、文档大小一台 64GB 内存的服务器MongoDB 的 cacheSizeGB 可以设为 60GB 吗为什么答案将在第 40 章末尾揭晓上一章思考题答案WiredTiger 的 MVCC 使用追加新版本的方式——每次更新在原文档的物理位置附近创建一个新版本旧版本被标记为过时但不立即删除。旧版本由后台的 Checkpoint Cleanup 线程在确认没有活跃事务引用它之后清理。这就是为什么 WiredTiger 需要定期 Checkpoint 来回收旧版本占用的空间。两个事务——A 读 X 写 YB 读 Y 写 X——不会形成传统意义上的死锁因为 WiredTiger 使用乐观 MVCC 而非悲观锁。但会触发 WriteConflict——两个事务在各自 commit 时检测到自己读过的数据被对方修改了版本变化后提交的那个会被 abort 重试。MongoDB 不会死锁等待而是主动让后提交者失败并重试——这也是为什么事务需要自动重试。延伸阅读与资源MongoDB 实战进阶与内核修炼python入门Rquests从菜鸟脚本到企业级SDK的网络实战圣经Milvus向量数据库实战修炼从 0 到 1精通向量检索与生产落地后端工程师的 AI 转型第一课Ollama 与私有化大模型实战10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析
1. 项目背景业务场景本地生活电商准备迎接年度最大促销——“618 年中大促”。运维团队接到死命令系统必须扛住 10 万 QPS 的读写混合负载P99 延迟 100ms。目前的架构——3 分片 × 3 节点复制集8 核 32GB × 9 台服务器。压测结果显示——当前配置在 3 万 QPS 时 P99 延迟已经到 300ms距离目标还有 3 倍差距。容量规划上也有盲区——运维不知道现有的磁盘能支撑多久日均增量 50GB磁盘剩余 1TB——大约 20 天就会满但还没有扩容预算内存的工作集到底多大也不清楚现在是 32GB但 WiredTiger 缓存配置了 16GB——够不够CPU 瓶颈到底是在 MongoDB Server 层还是 WiredTiger 层还是网络层。痛点性能调优没有银弹。NUMA 架构可能导致 MongoDB 只用到一半内存透明大页Transparent Huge Pages可能让 WiredTiger 的 4KB 页碎成渣文件系统选择ext4 vs xfs影响fsync性能磁盘 IOPS 不够导致 Checkpoint 期间的写入毛刺连接池、网络、内核参数……每一个环节都可能成为瓶颈。2. 项目设计小胖盯着压测报告上 P99 300ms 的红线大师我们 9 台服务器配了最强的 SSD、64 核 CPU、256GB 内存结果 3 万 QPS 就 P99 300ms这不科学大师性能调优第一步——不猜用数据说话。把压测期间的 MongoDB 指标拉出来我帮你定位瓶颈在哪一层。小胖我看过了CPU 85%IOPS 15000内存用了 90%连接池也没满……感觉全满了大师全满等于没有重点。我们按USE 方法论——逐一检查 Utilization利用率、Saturation饱和度、Errors错误数定位瓶颈的精确位置。CPU85% 是整体利用率但 MongoDB 是单进程的——如果是在 64 核机上只用了 8 核其他核空闲那整体 85% 其实意味着那 8 核已经满载了。用mpstat看每核利用率。IOPS15000 IOPS 看起来高——但对比你的 SSD 的标称能力假设 50000 IOPS还有余地。问题可能是 Checkpoint 期间的 IO 尖峰导致的抖动而不是平均 IOPS。内存90% 用在哪如果 WiredTiger 缓存只有 16GB而工作集是 50GB缓存淘汰频繁导致额外的磁盘 IO——这才是真正的瓶颈。技术映射USE 方法论——CPU 看每核利用率内存看缓存命中率和 eviction磁盘看 IOPS 的分布平均 vs P99网络看带宽和重传率。小胖那怎么找到工作集大小大师工作集大小 活跃查询中频繁访问的数据和索引的总和。估算方法——在高峰期运行db.serverStatus().wiredTiger.cache查看缓存使用率。如果 16GB 缓存中有 14GB 在被频繁访问且 eviction 0——说明工作集 16GB缓存不够。实际工作集 缓存当前使用量 因淘汰而额外产生的磁盘读对应的数据量。技术映射工作集 ≈ 缓存大小 × (1 eviction_io读 / 缓存命中)。如果缓存命中率 95%说明工作集显著大于缓存。小白容量规划怎么做磁盘、内存、CPU 各留多少余量大师一张表说清楚三者的规划资源规划公式警戒线磁盘(当前数据大小 日均增量 × 保留天数) × 1.5索引碎片使用率 70% 开始扩容内存工作集大小 × 1.2 2GB系统开销WiredTiger 缓存命中 95% 或 eviction 0CPU(目标 QPS × 查询平均 CPU 时间) × 1.3单核利用率 80% 或整体 CPU 70%小胖那系统调优呢我听人说 NUMA、透明大页、文件系统这些都要调大师对。快速清单NUMAnumactl --interleaveall mongod——防止 MongoDB 被限制在单 NUMA 节点上只能用一半内存。透明大页echo never /sys/kernel/mm/transparent_hugepage/enabled——WiredTiger 的 4KB 页和 2MB 大页冲突。文件系统XFS 比 ext4 更适合高并发小 IO——WiredTiger 大量 4KB 页读写更匹配 XFS 的 allocator。readaheadWiredTiger 有自己的预读逻辑——操作系统层的 readahead 反而干扰了——设为 8-16KB而非默认的 128KB。ulimit文件描述符ulimit -n 64000进程数ulimit -u 64000。swappinessvm.swappiness 1——尽量不使用 swap避免 WiredTiger 缓存被换出。大师总结今天记住——性能调优三步走USE 方法找瓶颈系统参数做基线NUMA/THP/XFS容量规划留余量30% 磁盘 20% CPU 缓存命中 95%。最后别忘了——压测后和压测中都要监控所有指标单靠压测报告的数字是片面的。3. 项目实战3.1 环境准备需要 Linux 服务器环境用于系统级调优。Docker 容器内部分参数NUMA/THP受宿主机控制。3.2 分步实现步骤一系统级性能基线检查# 内核参数检查清单 # 1. 透明大页状态cat/sys/kernel/mm/transparent_hugepage/enabled# 期望: [never] 或 always madvise [never] —— never 最前面表示当前禁用# 禁用命令: echo never /sys/kernel/mm/transparent_hugepage/enabled# 2. 内存交换倾向sysctlvm.swappiness# 期望: 1尽量不用 swap# 3. 文件描述符限制ulimit-n# 期望: 64000# 4. 磁盘 I/O 调度器SSD 推荐 noop 或 nonecat/sys/block/sda/queue/scheduler# 对 NVMe SSD: [none] 多队列无调度# 5. 文件系统预读blockdev--getra/dev/sda# 期望: 8-16KB——WiredTiger 有自己的预读逻辑# 6. NUMA 状态numactl--hardware# 如果有多 NUMA 节点——mongod 启动时用 numactl --interleaveall 绑定步骤二工作集与缓存命中率诊断// working-set-diagnose.js —— 工作集诊断use adminvarsdb.serverStatus()varcaches.wiredTiger.cachevarcacheUsedMBcache[bytes currently in the cache]/1024/1024varcacheMaxMBcache[maximum bytes configured]/1024/1024vardirtyMB(cache[tracked dirty bytes in the cache]||0)/1024/1024varpagesReadcache[pages read into cache]||0varpagesEvicted(cache[pages evicted by eviction server]||0)(cache[pages evicted by application threads]||0)print( 工作集诊断 )print(缓存使用:,cacheUsedMB.toFixed(0),MB /,cacheMaxMB.toFixed(0),MB,(,(cacheUsedMB/cacheMaxMB*100).toFixed(1),%))print(脏页:,dirtyMB.toFixed(0),MB)print(页读入:,pagesRead)print(页淘汰:,pagesEvicted)// 粗略的缓存命中率估计vartotalPageAccesspagesReadcache[pages requested from the cache]varhitRatetotalPageAccess0?(1-pagesRead/totalPageAccess)*100:nullif(hitRate!null){print(缓存命中率:,hitRate.toFixed(1),%,hitRate95?PASS:⚠ 建议增大缓存)}// 工作集估算// 如果 eviction 0 且频繁——说明工作集 当前缓存if(cache[pages evicted by application threads]0){print(⚠ 应用线程被迫淘汰——缓存严重不足)print( 建议 cacheSizeGB 至少增加到当前使用量的 1.5 倍)}步骤三容量规划计算器// capacity-planning.js —— 容量规划计算varsdb.serverStatus()vardbStatsdb.getSiblingDB(local_life).stats()// 输入参数运维填写vargrowthRatePerDay50// GB/天varretentionDays90// 保留天数vartargetQP100000// 目标 QPSvaravgQueryTimeMs2// 平均查询耗时// 1. 磁盘规划varcurrentSizeGBdbStats.dataSize/1024/1024/1024varindexSizeGBdbStats.indexSize/1024/1024/1024vartotalCurrentGBcurrentSizeGBindexSizeGBvarprojectedSizeGBtotalCurrentGBgrowthRatePerDay*retentionDaysvarsafetyMarginGBprojectedSizeGB*0.3// 30% 安全余量print( 容量规划 )print(当前数据:,currentSizeGB.toFixed(1),GB 索引:,indexSizeGB.toFixed(1),GB)print(,retentionDays,天后预计:,projectedSizeGB.toFixed(0),GB)print(建议磁盘:,(projectedSizeGBsafetyMarginGB).toFixed(0),GB)// 2. 内存规划varcacheSizeGBcache[maximum bytes configured]/1024/1024/1024varrecommendedCache(cacheUsedMB/1024)*1.5// 当前使用的 1.5 倍print(\n当前缓存:,cacheSizeGB.toFixed(1),GB, 建议:,recommendedCache.toFixed(1),GB)// 3. CPU 规划varestimatedCpuPerQueryavgQueryTimeMs/1000// 秒varrequiredCpuSectargetQP*estimatedCpuPerQueryvarrequiredCoresMath.ceil(requiredCpuSec*1.3)// 30% 余量print(\n目标 QPS:,targetQP,→ 需要约,requiredCores,个 CPU 核心)步骤四磁盘 IOPS 与 Checkpoint 毛刺诊断// iops-check.js —— 磁盘 IO 与 Checkpoint 监控// 在 mongosh 中每 2 秒采样一次 IO 相关指标functionsampleIO(){varsdb.serverStatus()varwts.wiredTigerreturn{time:newDate(),reads:wt[block-manager][blocks read]||0,writes:wt[block-manager][blocks written]||0,checkpointMs:wt.checkpoint?.[most recent time msecs]||0,evictionApp:wt.cache[pages evicted by application threads]||0}}varbeforesampleIO()sleep(5000)varaftersampleIO()varblocksReadafter.reads-before.readsvarblocksWrittenafter.writes-before.writesvariops(blocksReadblocksWritten)/5// 5 秒间隔 → 每秒 IOPSprint( IOPS 采样 (5秒) )print(读块:,blocksRead,写块:,blocksWritten)print(估算 IOPS:,iops.toFixed(0))print(最近 Checkpoint 耗时:,after.checkpointMs,ms)print(应用线程淘汰:,after.evictionApp-before.evictionApp)// 如果 Checkpoint 1000ms1秒——说明脏页过多checkpoint 期间 IO 风暴// 如果 evictionApp 在 5 秒内新增 0——缓存不够应用被迫参与淘汰步骤五mongostat mongotop 实时监控# mongostat 实时指标 # 每秒刷新一次输出 QPS、连接数、内存、锁等关键指标mongostat--urimongodb://admin:passhost:27017/?authSourceadmin-n301# 关键列解读# insert/query/update/delete: 每秒操作数# vsize/res: 虚拟内存/物理内存# qr/qw: 读/写队列长度 0 说明请求在等待# ar/aw: 活跃读/写连接数# netIn/netOut: 网络流量# conn: 连接数# dirty: 脏页百分比# used: 缓存使用率# mongotop 集合级读写负载 mongotop--urimongodb://admin:passhost:27017/?authSourceadmin5# 每 5 秒刷新一次显示每个集合的读写时间占比# 找出最忙的集合——读写时间最高的那个 → 优化它的索引或分片步骤六火焰图定位 CPU 热点# perf 采集 30 秒调用栈并生成火焰图核心步骤# 1. 采集在生产环境低峰期进行sudoperf record-F99-p$(pgrep mongod)-g--sleep30# 2. 生成火焰图sudoperf script|./FlameGraph/stackcollapse-perf.plmongod.folded ./FlameGraph/flamegraph.pl mongod.foldedmongod_flamegraph.svg# 3. 分析火焰图中的主要 CPU 消耗# 常见热点# - __wt_btree_insert → 索引写入热点 → 考虑批量写入或分片# - __wt_row_search → B-Tree 查找 → 索引选择性差或缺少索引# - mongo::BSONObj::toString → BSON 序列化 → 文档过大或返回字段过多# - malloc/free → 频繁内存分配 → 文档碎片化或工作集不稳定3.3 完整代码清单文件用途mongodb-lab/tuning/kernel-check.sh内核参数基线检查mongodb-lab/tuning/working-set-diagnose.js工作集与缓存命中率诊断mongodb-lab/tuning/capacity-planning.js容量规划计算器mongodb-lab/tuning/iops-checkpoint.jsIOPS 与 Checkpoint 毛刺诊断mongodb-lab/tuning/mongostat-capture.shmongostat 捕获脚本3.4 测试验证use admin// 1. 验证系统指标可采集varsdb.serverStatus()print(WiredTiger:,s.wiredTiger?PASS:FAIL)print(连接:,s.connections?PASS:FAIL)// 2. 验证磁盘统计vardbStatsdb.getSiblingDB(local_life).stats()print(磁盘统计:,dbStats.dataSize0?PASS:FAIL)// 3. 验证 Checkpoint 信息varcpdb.serverStatus().wiredTiger.checkpointprint(Checkpoint:,cp?PASS:FAIL)// 4. 验证 mongostat 可用// 在宿主机命令行运行: mongostat --versionprint(\n 性能调优工具验证完成 )4. 项目总结4.1 性能调优速查清单层级调优项推荐值/操作内核透明大页禁用 (never)内核swappiness1内核readahead8-16KB文件系统XFS优于 ext4硬件NUMAnumactl --interleaveallMongoDBcacheSizeGB物理内存 × 50%-70%MongoDBOplog 大小24-48 小时写入量MongoDB连接池 maxPoolSize50-100按 QPS 调应用批量写入bulkWrite 替代逐条 insert应用原子更新$inc filter替代 read-then-write4.2 适用场景极端性能调优适用大促前的容量评估和压测调优。数据库迁移到新硬件后的参数复查。周期性性能衰退的根因分析碎片、缓存命中率下降。新业务上线前的工作集评估和资源申请。4.3 注意事项注意事项说明内核参数修改后需重启 mongodTHP、swappiness 等修改需要 mongod 重启才生效perf 采集有性能开销生产环境低峰期采集 30s不要长时间运行XFS 优于 ext4 但并非银弹ext4 在纯读场景下可能更快容量规划的数字是经验值根据实际压测数据调整余量——模型需要校准4.4 常见踩坑经验故障案例一NUMA 导致只用一半内存某 128GB 服务器上 MongoDB 设置了cacheSizeGB: 80但实际只用了 40GB一半。根因服务器是双路 NUMA 架构mongod 进程只在一个 NUMA 节点上分配了内存——另一个节点的 64GB 空闲。解决numactl --interleaveall mongod或在 systemd service 中配置CPUAffinity和MemoryPolicyinterleave。故障案例二Checkpoint 期间的磁盘 IO 风暴某 SSD 服务器的 MongoDB 每 60 秒出现一次 2-3 秒的写入毛刺——Checkpoint 期间脏页刷盘产生大量 IO。根因脏页比例过高30%一次性刷盘量大。解决缩短 Checkpoint 间隔到 30 秒checkpoint(wait30,log_size1GB)使脏页更频繁但更平缓地刷盘同时增大 WiredTiger 缓存以减少总脏页量。故障案例三压缩算法选 snappy 导致磁盘膨胀某团队用 snappy 做默认压缩半年后磁盘使用率超预期——数据量 800GBsnappy 压缩后还有 650GB压缩率不到 20%。改用 zstd 后降到 420GB——节省了 35% 的空间。代价是 CPU 升高 15%但磁盘成本节省远大于 CPU 成本。解决压缩算法要根据数据特征选——高重复度数据日志/JSON用 zstd 收益大二进制数据图片/文件压缩率极低时用 none。4.5 思考题如果 WiredTiger 缓存命中率是 99%——说明缓存基本够用。但 P99 延迟仍然很高——可能的原因是什么提示不只看缓存命中还要看锁、网络、文档大小一台 64GB 内存的服务器MongoDB 的 cacheSizeGB 可以设为 60GB 吗为什么答案将在第 40 章末尾揭晓上一章思考题答案WiredTiger 的 MVCC 使用追加新版本的方式——每次更新在原文档的物理位置附近创建一个新版本旧版本被标记为过时但不立即删除。旧版本由后台的 Checkpoint Cleanup 线程在确认没有活跃事务引用它之后清理。这就是为什么 WiredTiger 需要定期 Checkpoint 来回收旧版本占用的空间。两个事务——A 读 X 写 YB 读 Y 写 X——不会形成传统意义上的死锁因为 WiredTiger 使用乐观 MVCC 而非悲观锁。但会触发 WriteConflict——两个事务在各自 commit 时检测到自己读过的数据被对方修改了版本变化后提交的那个会被 abort 重试。MongoDB 不会死锁等待而是主动让后提交者失败并重试——这也是为什么事务需要自动重试。延伸阅读与资源MongoDB 实战进阶与内核修炼python入门Rquests从菜鸟脚本到企业级SDK的网络实战圣经Milvus向量数据库实战修炼从 0 到 1精通向量检索与生产落地后端工程师的 AI 转型第一课Ollama 与私有化大模型实战10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析
