MongoDB Tracing Profiler基于 CycleClock 的轻量级调用树剖析工具实战指南【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo导读MongoDB 服务器mongod是典型的高并发 C 服务其内部热点函数的耗时分析一直依赖外部性能剖析器。tracing_profiler是 MongoDB 仓库中自带的一套轻量级、可嵌入进程内的调用树剖析工具开发者只需在目标函数中插入一行宏即可统计该作用域span的总耗时、进入次数与剖析自身开销并通过serverStatus命令以tracing_profiler字段导出。本文将完整讲解其构建开关、代码插桩方式、数据采集与火焰图生成流程并结合 profiler.h 与 profiler_internal.cpp 的源码实现深入剖析其调用树组织、线程局部存储与并发安全设计帮助你掌握一套可复用的零外部依赖的性能观测方案。工具概览与设计目标该工具位于仓库 src/mongo/util/tracing_profiler核心文档为 README.md。它解决的问题非常聚焦在 mongod 进程内部、以纳秒级精度记录开发者显式标注的代码作用域的执行统计。每个被标注的作用域span会收集以下三类数据total time总耗时进入该作用域到离开该作用域之间花费的总时间count进入次数该作用域被进入等价于函数被调用的次数approximate overhead剖析开销剖析本身引入的估算开销用于在结果中剔除。与外部采样剖析器不同这里的时间测量基于CycleClock实现取自 src/third_party/abseil-cpp/dist/absl/base/internal/cycleclock.cc通过读取 CPU 周期计数再除以周期频率换算为纳秒。由于单次测量的典型开销只有约 15~20ns因此非常适合剖析快速执行的热点函数README 明确给出该量级实际数值取决于硬件与节点宽度见下文开销校准。一个关键特性是剖析器会像维护调用栈一样维护嵌套作用域外层 span 尚未结束时进入的内层 span会成为外层 span 的子节点最终形成一棵完整的调用树。构建与启用开关剖析功能默认关闭需要通过 Bazel 构建选项显式开启bazel build --use-tracing-profileron ...对应的构建宏为MONGO_CONFIG_USE_TRACING_PROFILER由构建系统生成到mongo/config.h。在 profiler.h 中可以看到它的分支逻辑开启时MONGO_PROFILER_SPAN_ENTER(spanName)展开为::mongo::tracing_profiler::internal::GlobalProfilerService::enterSpanspanName()真实进入全局剖析服务关闭时两个宏分别退化为构造一个空的ProfilerSpan{}与空操作span.release()也就是 README 所说的no-op 空定义。因此插桩代码可以在任何构建配置下安全编译未开启剖析时零开销ProfilerSpan被标记为[[maybe_unused]]以避免关闭模式下产生未使用变量告警。值得注意的细节是 span 名称是作为模板参数FixedString传入的编译期即可完成字符串到TagId的绑定见 profiler_internal.h 的ProfilerTagSource运行时只传递 32 位整数TagId避免热点路径上的字符串查找开销。代码插桩一行宏标注热点函数README 给出的最小插桩示例#include mongo/util/tracing_profiler/profiler.h void myFunction(...) { auto __spanGuard MONGO_PROFILER_SPAN_ENTER(myNamespace::myFunction); ... do stuff ... }其中__spanGuard是ProfilerSpan类型的 RAII 守卫对象。从 profiler.h 可以看到它的生命周期管理构造时保存当前线程 shard 指针与进入时的SpanState节点 ID 起始周期数析构函数自动调用release()向 shard 上报离开事件拷贝构造、移动构造与赋值均被delete确保守卫只能通过作用域离开自动触发不会重复上报。因此函数中途return、抛出异常都能正确结束 span。对于需要提前结束的场景提供了配套宏MONGO_PROFILER_SPAN_LEAVE(span)其展开为span.release()。该宏同样在未启用构建时退化为空操作。在 profiler_bm.cpp 中可以看到实际嵌套使用多个 span 的端到端示例BM_end2endX5Narrow它演示了外层 span1 内嵌套 span2/span3随后再嵌套 span4/span5的典型写法是理解嵌套语义最直观的参考。数据采集profile_mongod.py 工作流采集的前提是mongod 已启用--use-tracing-profileron构建且机器上安装有mongosh命令行工具并在 PATH 中README 的 Requirements 明确要求。核心用法# 采集 mongod profiler 统计 60 秒并把作用域测量结果写入 perf.json buildscripts/tracing_profiler/profile_mongod.py --sleep 60 perf.json # 或者在等待 CTRL-C 信号期间持续采集 buildscripts/tracing_profiler/profile_mongod.py perf.json脚本 buildscripts/tracing_profiler/profile_mongod.py 的执行逻辑非常清晰采样前快照通过mongosh --quiet --eval print(EJSON.stringify(db.runCommand({serverStatus: 1}).tracing_profiler))获取当前tracing_profiler统计即累积值等待窗口若指定--sleep N则等待 N 秒否则一直等待直至收到CTRL-CSIGINT脚本通过signal.signal设置 stop_event采样后快照再次执行同样的 serverStatus 查询差分输出调用after_metrics.subtract(before_metrics)实现在 buildscripts/tracing_profiler/profilerlib.py 的CallMetrics.visit_add中按mult-1递归做差只保留采样窗口内的增量测量以 JSON 形式打印。之所以要做差分是因为serverStatus返回的是自进程启动以来的累积值通过前后两次快照相减才能得到特定时间窗内的剖析数据。透传参数脚本同时支持向 mongosh 透传连接参数可直接用-h查看参数说明-s, --sleep N采集 N 秒不指定则无限期等待 CTRL-C-u, --username认证用户名-p, --password认证密码--host连接的服务器地址--port连接的端口--tls对所有连接启用 TLS--tlsAllowInvalidCertificates允许连接证书无效的服务器--tlsAllowInvalidHostnames允许连接主机名不匹配的服务器数据从哪来serverStatus 的 tracing_profiler 字段采样命令读取的tracing_profiler字段由 profiler_internal.cpp 中的ProfilerStatsServerStatusSection注册通过ServerStatusSectionBuilderProfilerStatsServerStatusSection(tracing_profiler)。includeByDefault()返回true因此默认就会出现在serverStatus输出中。generateSection调用GlobalProfilerService::getProfiler()-getMetrics()获取聚合快照再经ProfilerMetrics::toBson()序列化。序列化后的每个 span 节点包含如下字段见toBson实现周期数通过cycles / frequency * 1e9换算为纳秒id节点在调用树中的唯一编号namespan 名称来自ProfilerTag的字符串parentId父节点 ID根节点为 0totalNanos在该调用路径上花费的总时间netNanos扣除估算剖析开销后的净时间exclusiveNanos扣除全部子节点与剖析开销后的独占时间count该作用域被进入的次数。可以对照 golden 测试的期望输出 profiler_service_simple.txt例如doZ1节点count100、totalNanos9000000000其子节点doY1、doY2各占3000000000exclusiveNanos2250000000正好是总耗时减去两个子节点耗时的结果完整展示了调用树的父子关系与各项指标的勾稽关系。数据格式化profile_format.py采集到的 JSON 可以通过 buildscripts/tracing_profiler/profile_format.py 转换成两种便于分析的格式。输出 TSV便于表格分析# 打印为 TSV例如在 Google Sheets 中分析 buildscripts/tracing_profiler/profile_format.py -i perf.json -f tsvTSV 输出的表头为id、name、parentId、totalNanos、netNanos、exclusive_nanos、count每行一个 span根节点 id0 被跳过非常适合排序、筛选与透视分析。输出 folded 格式并生成火焰图# 从测量结果生成火焰图 buildscripts/tracing_profiler/profile_format.py -i perf.json -f folded perf.folded ~/FlameGraph/flamegraph.pl perf.folded perf.svgfolded 格式是 Brendan Gregg 火焰图的标准输入格式每行形如A;B;C 12345分号分隔调用路径末尾为耗时。print_folded_visit从根节点递归遍历整棵调用树用;连接父子 span 名称叶子值为exclusive_nanos。按单次调用归一化# 归一化到 myNamespace::myFunction1 的单次平均调用 buildscripts/tracing_profiler/profile_format.py -i perf.json -f folded -n myNamespace::myFunction1 perf.folded ~/FlameGraph/flamegraph.pl perf.folded perf.svg-n/--normalize-count接受两种值见 profile_format.py数字将全部指标除以该数值span 名称先通过CallMetrics.find_span按.分隔的路径在调用树中定位 span再用该 span 的count作为除数通过add_weighted(metrics, 1.0 / normalize_count)将整棵调用树按单次平均调用缩放。这样火焰图展示的就是平均执行一次目标函数时各子路径的耗时分布适合分析固定工作负载下某个关键函数的内部热点。另外-e/--keep-empty默认会移除count 0的空 spanremove_empty_spans保证输出聚焦于实际执行过的路径。Profiler 设计调用树、线程分片与并发安全数据模型调用树CallTreeREADME 明确指出剖析器以调用树形式收集所有指标树中节点代表测量作用域某作用域活跃期间进入并退出的嵌套作用域成为其子节点树中的一条路径等价于一条调用栈。源码层面profiler_internal.h 的CallTree::Node由三部分组成parentId父节点 ID、tagId关联的 Tag、children子节点集合。子节点集合采用ChildrenMap它是一个std::variant可表示为两种容器ChildrenInlinedMap最多内联 4 个(TagId, NodeId)的定长数组InlinedMapTagId, NodeId, 4对子节点少的窄节点narrow node零堆分配、访问最快ChildrenHashMap基于absl::flat_hash_map配以std::hardware_destructive_interference_size对齐的分配器用于子节点较多的宽节点wide node。CallTree::getOrInsertChildNode中可以看到内联数组写满后自动升级为哈希表的迁移逻辑前 4 个子节点以内联数组保存插入第 5 个时把旧条目搬入新建的ChildrenHashMap。CallMetrics::NodeMetrics则对每个节点保存两个原子计数器std::atomic_int64_t cycles在该节点花费的周期总数与count进入-离开次数。线程分片ThreadLocalShard为了避免缓存同步争用每个参与线程维护独立的测量状态README 明确说明即 profiler_internal.h 的Profiler::ThreadLocalShard每个 shard 持有独立的CallMetrics调用树 节点指标只能由关联线程自身修改其他线程只允许读取树在预热后基本保持不可变——大多数 span 在第一次进入时创建节点之后命中tryGetChildNode的只读快速路径由于节点分配使用按 cache line 对齐的内存aligned_allochardware_destructive_interference_size不同线程的计数器不会发生伪共享。enterSpanImpl的快速路径profiler_internal.h是理解性能的关键先tryGetChildNode只读查找子节点命中即用未命中MONGO_unlikely分支才调用getOrInsertChildNodeSafe该路径需要加unique_lock写锁来插入新节点。由于插入是相对罕见的事件绝大多数进入/离开操作都是无锁的只读路径加两次原子累加cycles.store/count.store使用memory_order_relaxed这正是 15~20ns 级开销的来源。并发安全策略README 归纳了仅有的两类竞态及其解法一个线程修改调用树另一个线程导出统计通过shared_mutexshard 内的_sharedMutex解决。修改树是罕见事件加独占锁导出统计走共享锁一个线程更新节点指标另一个线程导出统计通过原子读写解决——指标计数器本身就是std::atomic_int64_t导出方用memory_order_relaxedload 快照。Profiler全局对象同样用一把shared_mutex保护_shards集合与累积的_callMetrics。getMetricsImpl的聚合流程是在共享锁保护下先复制全局_callMetrics再遍历所有注册 shard逐个调用getCallMetrics()取快照并append到聚合结果见 profiler_internal.cpp。CallMetrics::appendVisit递归合并两棵同构调用树按TagId匹配节点、累加count与cycles必要时创建缺失节点。线程退出时的处理也值得注意ThreadLocalShard的析构函数调用unregisterShard把该线程的最终指标append进全局_callMetrics见 profiler_internal.cpp因此已退出线程的测量结果也不会丢失仍会进入后续聚合。开销校准measureOverheadnetNanos与exclusiveNanos依赖对剖析开销的估算。measureOverheadprofiler_internal.cpp在启动时通过内建基准测量单次测量的平均周期开销narrow 场景doX5Narrow()连续进入 5 个内联数组节点1 个根 2 层嵌套共 5 个 spanwide 场景doX25Wide()循环 5 次每次进入 1 个宽节点并在其下嵌套 5 个子节点共 25 个 span各采样 32 次取中位数std::nth_element并把每次循环的总周期数除以 span 个数得到单次测量开销。由于开销主要与父节点的容器类型内联数组 vs 哈希表相关这两类测量就足以给出较准的估计。最终的narrowNodeOverheadCycles/wideNodeOverheadCycles存入OverheadCycles并通过日志LOGV2 id 8837400打印Estimated overhead of tracing profiler span measurement in nanos。指标计算netNanos 与 exclusiveNanosComputedMetricsBuilder::visitprofiler_internal.cpp自底向上计算每类指标README 中的三条定义对应如下实现totalNanos节点自身cycles累计值直接换算netNanosnetCycles 节点测得周期数 − 子树总开销totalOverheadCycles 自身开销的一半。实现注释解释了原因一次耗时测量本身就包含测量动作一半的开销所以节点自身只能扣一半而子节点的开销在父节点测量中是完整被观察到的可以全扣exclusiveNanosexclusiveCycles 本节点netCycles− 所有子节点netCycles之和即自身独占时间排除子节点与剖析代码。README 同时提醒估算开销可能不精确它基于校准出的平均单次测量时间并假设测量本身也包含了自身开销的大约一半。测试与基准如何验证正确性与性能Golden 测试单元测试 profiler_test.cpp 覆盖两类场景CallTree结构测试CallTree_Flat、ProfilerStack_Nested、ProfilerStack_NodesNarrow、ProfilerStack_NodesWide验证子节点查找/插入的幂等性——重复插入相同TagId返回同一NodeId以及窄节点内联数组与宽节点哈希表的构建正确性ProfilerService_Simplegolden 测试使用MockCycleClock每次now()前进 10 个周期、频率 1000对应 10ms/周期确定性驱动时间执行 100 次doZ → doY → doX的嵌套调用后导出 BSON与 golden 文件 profiler_service_simple.txt 逐字段比对。该文件呈现的正是doZ1 → doY1/doY2 → doX的完整调用树及各节点的 total/net/exclusive 数值是理解输出格式最直观的样例。测试由 BUILD.bazel 中的tracing_profiler_testmongo_cc_unit_test承载golden 数据通过data依赖注入。性能基准profiler_bm.cpp 使用 Google Benchmark 定义了三个基准tracing_profiler_bm目标BM_enterLeaveSpanX5Narrow与BM_enterLeaveSpanX25Wide不依赖全局服务直接操作ThreadLocalShard分别测量窄/宽节点下的 enter/leave 原始开销线程数范围 1~16ThreadRange(1, 16)BM_end2endX5Narrow仅启用MONGO_CONFIG_USE_TRACING_PROFILER时编译走完整的MONGO_PROFILER_SPAN_ENTER/LEAVE宏端到端路径。这些基准既用于验证单次测量约 15~20ns的声明也用于校准measureOverhead中的窄/宽节点开销常数。小结与适用前提tracing_profiler提供了一条从代码插桩 → 进程内采集 → serverStatus 导出 → 差分窗口 → TSV/火焰图的完整性能观测链路。它的核心优势在于零外部依赖基于 CycleClock 的周期计数单次测量仅约 15~20ns适用于快速函数调用树语义嵌套 span 自动形成调用树路径等价于调用栈可还原真实的执行结构低竞争并发设计线程局部 shard 原子计数器 少量共享锁兼顾热路径性能与导出安全。使用时的前提与限制需要明确必须以--use-tracing-profileron重新构建 mongod否则宏为 no-op需要mongosh在 PATH 中netNanos/exclusiveNanos依赖校准的开销估算存在一定误差README 已注明产物仅覆盖开发者显式插桩的 span不会自动捕获未标注的代码路径。对于定位哪个函数占用了多少时间、被调用了多少次、自身与子树开销如何这类问题它是在 mongod 内部即可完成、无需停机附加外部剖析器的实用方案。相关源码与资源索引关联文档README.md公开接口与宏定义profiler.h核心实现调用树、聚合、serverStatus 导出profiler_internal.cpp内部数据结构与线程分片profiler_internal.h周期时钟封装cycleclock.h单元测试profiler_test.cppGolden 输出样例profiler_service_simple.txt采集脚本profile_mongod.py格式化脚本profile_format.py数据处理库profilerlib.py性能基准profiler_bm.cpp构建定义BUILD.bazel【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MongoDB Tracing Profiler：基于 CycleClock 的轻量级调用树剖析工具实战指南
MongoDB Tracing Profiler基于 CycleClock 的轻量级调用树剖析工具实战指南【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo导读MongoDB 服务器mongod是典型的高并发 C 服务其内部热点函数的耗时分析一直依赖外部性能剖析器。tracing_profiler是 MongoDB 仓库中自带的一套轻量级、可嵌入进程内的调用树剖析工具开发者只需在目标函数中插入一行宏即可统计该作用域span的总耗时、进入次数与剖析自身开销并通过serverStatus命令以tracing_profiler字段导出。本文将完整讲解其构建开关、代码插桩方式、数据采集与火焰图生成流程并结合 profiler.h 与 profiler_internal.cpp 的源码实现深入剖析其调用树组织、线程局部存储与并发安全设计帮助你掌握一套可复用的零外部依赖的性能观测方案。工具概览与设计目标该工具位于仓库 src/mongo/util/tracing_profiler核心文档为 README.md。它解决的问题非常聚焦在 mongod 进程内部、以纳秒级精度记录开发者显式标注的代码作用域的执行统计。每个被标注的作用域span会收集以下三类数据total time总耗时进入该作用域到离开该作用域之间花费的总时间count进入次数该作用域被进入等价于函数被调用的次数approximate overhead剖析开销剖析本身引入的估算开销用于在结果中剔除。与外部采样剖析器不同这里的时间测量基于CycleClock实现取自 src/third_party/abseil-cpp/dist/absl/base/internal/cycleclock.cc通过读取 CPU 周期计数再除以周期频率换算为纳秒。由于单次测量的典型开销只有约 15~20ns因此非常适合剖析快速执行的热点函数README 明确给出该量级实际数值取决于硬件与节点宽度见下文开销校准。一个关键特性是剖析器会像维护调用栈一样维护嵌套作用域外层 span 尚未结束时进入的内层 span会成为外层 span 的子节点最终形成一棵完整的调用树。构建与启用开关剖析功能默认关闭需要通过 Bazel 构建选项显式开启bazel build --use-tracing-profileron ...对应的构建宏为MONGO_CONFIG_USE_TRACING_PROFILER由构建系统生成到mongo/config.h。在 profiler.h 中可以看到它的分支逻辑开启时MONGO_PROFILER_SPAN_ENTER(spanName)展开为::mongo::tracing_profiler::internal::GlobalProfilerService::enterSpanspanName()真实进入全局剖析服务关闭时两个宏分别退化为构造一个空的ProfilerSpan{}与空操作span.release()也就是 README 所说的no-op 空定义。因此插桩代码可以在任何构建配置下安全编译未开启剖析时零开销ProfilerSpan被标记为[[maybe_unused]]以避免关闭模式下产生未使用变量告警。值得注意的细节是 span 名称是作为模板参数FixedString传入的编译期即可完成字符串到TagId的绑定见 profiler_internal.h 的ProfilerTagSource运行时只传递 32 位整数TagId避免热点路径上的字符串查找开销。代码插桩一行宏标注热点函数README 给出的最小插桩示例#include mongo/util/tracing_profiler/profiler.h void myFunction(...) { auto __spanGuard MONGO_PROFILER_SPAN_ENTER(myNamespace::myFunction); ... do stuff ... }其中__spanGuard是ProfilerSpan类型的 RAII 守卫对象。从 profiler.h 可以看到它的生命周期管理构造时保存当前线程 shard 指针与进入时的SpanState节点 ID 起始周期数析构函数自动调用release()向 shard 上报离开事件拷贝构造、移动构造与赋值均被delete确保守卫只能通过作用域离开自动触发不会重复上报。因此函数中途return、抛出异常都能正确结束 span。对于需要提前结束的场景提供了配套宏MONGO_PROFILER_SPAN_LEAVE(span)其展开为span.release()。该宏同样在未启用构建时退化为空操作。在 profiler_bm.cpp 中可以看到实际嵌套使用多个 span 的端到端示例BM_end2endX5Narrow它演示了外层 span1 内嵌套 span2/span3随后再嵌套 span4/span5的典型写法是理解嵌套语义最直观的参考。数据采集profile_mongod.py 工作流采集的前提是mongod 已启用--use-tracing-profileron构建且机器上安装有mongosh命令行工具并在 PATH 中README 的 Requirements 明确要求。核心用法# 采集 mongod profiler 统计 60 秒并把作用域测量结果写入 perf.json buildscripts/tracing_profiler/profile_mongod.py --sleep 60 perf.json # 或者在等待 CTRL-C 信号期间持续采集 buildscripts/tracing_profiler/profile_mongod.py perf.json脚本 buildscripts/tracing_profiler/profile_mongod.py 的执行逻辑非常清晰采样前快照通过mongosh --quiet --eval print(EJSON.stringify(db.runCommand({serverStatus: 1}).tracing_profiler))获取当前tracing_profiler统计即累积值等待窗口若指定--sleep N则等待 N 秒否则一直等待直至收到CTRL-CSIGINT脚本通过signal.signal设置 stop_event采样后快照再次执行同样的 serverStatus 查询差分输出调用after_metrics.subtract(before_metrics)实现在 buildscripts/tracing_profiler/profilerlib.py 的CallMetrics.visit_add中按mult-1递归做差只保留采样窗口内的增量测量以 JSON 形式打印。之所以要做差分是因为serverStatus返回的是自进程启动以来的累积值通过前后两次快照相减才能得到特定时间窗内的剖析数据。透传参数脚本同时支持向 mongosh 透传连接参数可直接用-h查看参数说明-s, --sleep N采集 N 秒不指定则无限期等待 CTRL-C-u, --username认证用户名-p, --password认证密码--host连接的服务器地址--port连接的端口--tls对所有连接启用 TLS--tlsAllowInvalidCertificates允许连接证书无效的服务器--tlsAllowInvalidHostnames允许连接主机名不匹配的服务器数据从哪来serverStatus 的 tracing_profiler 字段采样命令读取的tracing_profiler字段由 profiler_internal.cpp 中的ProfilerStatsServerStatusSection注册通过ServerStatusSectionBuilderProfilerStatsServerStatusSection(tracing_profiler)。includeByDefault()返回true因此默认就会出现在serverStatus输出中。generateSection调用GlobalProfilerService::getProfiler()-getMetrics()获取聚合快照再经ProfilerMetrics::toBson()序列化。序列化后的每个 span 节点包含如下字段见toBson实现周期数通过cycles / frequency * 1e9换算为纳秒id节点在调用树中的唯一编号namespan 名称来自ProfilerTag的字符串parentId父节点 ID根节点为 0totalNanos在该调用路径上花费的总时间netNanos扣除估算剖析开销后的净时间exclusiveNanos扣除全部子节点与剖析开销后的独占时间count该作用域被进入的次数。可以对照 golden 测试的期望输出 profiler_service_simple.txt例如doZ1节点count100、totalNanos9000000000其子节点doY1、doY2各占3000000000exclusiveNanos2250000000正好是总耗时减去两个子节点耗时的结果完整展示了调用树的父子关系与各项指标的勾稽关系。数据格式化profile_format.py采集到的 JSON 可以通过 buildscripts/tracing_profiler/profile_format.py 转换成两种便于分析的格式。输出 TSV便于表格分析# 打印为 TSV例如在 Google Sheets 中分析 buildscripts/tracing_profiler/profile_format.py -i perf.json -f tsvTSV 输出的表头为id、name、parentId、totalNanos、netNanos、exclusive_nanos、count每行一个 span根节点 id0 被跳过非常适合排序、筛选与透视分析。输出 folded 格式并生成火焰图# 从测量结果生成火焰图 buildscripts/tracing_profiler/profile_format.py -i perf.json -f folded perf.folded ~/FlameGraph/flamegraph.pl perf.folded perf.svgfolded 格式是 Brendan Gregg 火焰图的标准输入格式每行形如A;B;C 12345分号分隔调用路径末尾为耗时。print_folded_visit从根节点递归遍历整棵调用树用;连接父子 span 名称叶子值为exclusive_nanos。按单次调用归一化# 归一化到 myNamespace::myFunction1 的单次平均调用 buildscripts/tracing_profiler/profile_format.py -i perf.json -f folded -n myNamespace::myFunction1 perf.folded ~/FlameGraph/flamegraph.pl perf.folded perf.svg-n/--normalize-count接受两种值见 profile_format.py数字将全部指标除以该数值span 名称先通过CallMetrics.find_span按.分隔的路径在调用树中定位 span再用该 span 的count作为除数通过add_weighted(metrics, 1.0 / normalize_count)将整棵调用树按单次平均调用缩放。这样火焰图展示的就是平均执行一次目标函数时各子路径的耗时分布适合分析固定工作负载下某个关键函数的内部热点。另外-e/--keep-empty默认会移除count 0的空 spanremove_empty_spans保证输出聚焦于实际执行过的路径。Profiler 设计调用树、线程分片与并发安全数据模型调用树CallTreeREADME 明确指出剖析器以调用树形式收集所有指标树中节点代表测量作用域某作用域活跃期间进入并退出的嵌套作用域成为其子节点树中的一条路径等价于一条调用栈。源码层面profiler_internal.h 的CallTree::Node由三部分组成parentId父节点 ID、tagId关联的 Tag、children子节点集合。子节点集合采用ChildrenMap它是一个std::variant可表示为两种容器ChildrenInlinedMap最多内联 4 个(TagId, NodeId)的定长数组InlinedMapTagId, NodeId, 4对子节点少的窄节点narrow node零堆分配、访问最快ChildrenHashMap基于absl::flat_hash_map配以std::hardware_destructive_interference_size对齐的分配器用于子节点较多的宽节点wide node。CallTree::getOrInsertChildNode中可以看到内联数组写满后自动升级为哈希表的迁移逻辑前 4 个子节点以内联数组保存插入第 5 个时把旧条目搬入新建的ChildrenHashMap。CallMetrics::NodeMetrics则对每个节点保存两个原子计数器std::atomic_int64_t cycles在该节点花费的周期总数与count进入-离开次数。线程分片ThreadLocalShard为了避免缓存同步争用每个参与线程维护独立的测量状态README 明确说明即 profiler_internal.h 的Profiler::ThreadLocalShard每个 shard 持有独立的CallMetrics调用树 节点指标只能由关联线程自身修改其他线程只允许读取树在预热后基本保持不可变——大多数 span 在第一次进入时创建节点之后命中tryGetChildNode的只读快速路径由于节点分配使用按 cache line 对齐的内存aligned_allochardware_destructive_interference_size不同线程的计数器不会发生伪共享。enterSpanImpl的快速路径profiler_internal.h是理解性能的关键先tryGetChildNode只读查找子节点命中即用未命中MONGO_unlikely分支才调用getOrInsertChildNodeSafe该路径需要加unique_lock写锁来插入新节点。由于插入是相对罕见的事件绝大多数进入/离开操作都是无锁的只读路径加两次原子累加cycles.store/count.store使用memory_order_relaxed这正是 15~20ns 级开销的来源。并发安全策略README 归纳了仅有的两类竞态及其解法一个线程修改调用树另一个线程导出统计通过shared_mutexshard 内的_sharedMutex解决。修改树是罕见事件加独占锁导出统计走共享锁一个线程更新节点指标另一个线程导出统计通过原子读写解决——指标计数器本身就是std::atomic_int64_t导出方用memory_order_relaxedload 快照。Profiler全局对象同样用一把shared_mutex保护_shards集合与累积的_callMetrics。getMetricsImpl的聚合流程是在共享锁保护下先复制全局_callMetrics再遍历所有注册 shard逐个调用getCallMetrics()取快照并append到聚合结果见 profiler_internal.cpp。CallMetrics::appendVisit递归合并两棵同构调用树按TagId匹配节点、累加count与cycles必要时创建缺失节点。线程退出时的处理也值得注意ThreadLocalShard的析构函数调用unregisterShard把该线程的最终指标append进全局_callMetrics见 profiler_internal.cpp因此已退出线程的测量结果也不会丢失仍会进入后续聚合。开销校准measureOverheadnetNanos与exclusiveNanos依赖对剖析开销的估算。measureOverheadprofiler_internal.cpp在启动时通过内建基准测量单次测量的平均周期开销narrow 场景doX5Narrow()连续进入 5 个内联数组节点1 个根 2 层嵌套共 5 个 spanwide 场景doX25Wide()循环 5 次每次进入 1 个宽节点并在其下嵌套 5 个子节点共 25 个 span各采样 32 次取中位数std::nth_element并把每次循环的总周期数除以 span 个数得到单次测量开销。由于开销主要与父节点的容器类型内联数组 vs 哈希表相关这两类测量就足以给出较准的估计。最终的narrowNodeOverheadCycles/wideNodeOverheadCycles存入OverheadCycles并通过日志LOGV2 id 8837400打印Estimated overhead of tracing profiler span measurement in nanos。指标计算netNanos 与 exclusiveNanosComputedMetricsBuilder::visitprofiler_internal.cpp自底向上计算每类指标README 中的三条定义对应如下实现totalNanos节点自身cycles累计值直接换算netNanosnetCycles 节点测得周期数 − 子树总开销totalOverheadCycles 自身开销的一半。实现注释解释了原因一次耗时测量本身就包含测量动作一半的开销所以节点自身只能扣一半而子节点的开销在父节点测量中是完整被观察到的可以全扣exclusiveNanosexclusiveCycles 本节点netCycles− 所有子节点netCycles之和即自身独占时间排除子节点与剖析代码。README 同时提醒估算开销可能不精确它基于校准出的平均单次测量时间并假设测量本身也包含了自身开销的大约一半。测试与基准如何验证正确性与性能Golden 测试单元测试 profiler_test.cpp 覆盖两类场景CallTree结构测试CallTree_Flat、ProfilerStack_Nested、ProfilerStack_NodesNarrow、ProfilerStack_NodesWide验证子节点查找/插入的幂等性——重复插入相同TagId返回同一NodeId以及窄节点内联数组与宽节点哈希表的构建正确性ProfilerService_Simplegolden 测试使用MockCycleClock每次now()前进 10 个周期、频率 1000对应 10ms/周期确定性驱动时间执行 100 次doZ → doY → doX的嵌套调用后导出 BSON与 golden 文件 profiler_service_simple.txt 逐字段比对。该文件呈现的正是doZ1 → doY1/doY2 → doX的完整调用树及各节点的 total/net/exclusive 数值是理解输出格式最直观的样例。测试由 BUILD.bazel 中的tracing_profiler_testmongo_cc_unit_test承载golden 数据通过data依赖注入。性能基准profiler_bm.cpp 使用 Google Benchmark 定义了三个基准tracing_profiler_bm目标BM_enterLeaveSpanX5Narrow与BM_enterLeaveSpanX25Wide不依赖全局服务直接操作ThreadLocalShard分别测量窄/宽节点下的 enter/leave 原始开销线程数范围 1~16ThreadRange(1, 16)BM_end2endX5Narrow仅启用MONGO_CONFIG_USE_TRACING_PROFILER时编译走完整的MONGO_PROFILER_SPAN_ENTER/LEAVE宏端到端路径。这些基准既用于验证单次测量约 15~20ns的声明也用于校准measureOverhead中的窄/宽节点开销常数。小结与适用前提tracing_profiler提供了一条从代码插桩 → 进程内采集 → serverStatus 导出 → 差分窗口 → TSV/火焰图的完整性能观测链路。它的核心优势在于零外部依赖基于 CycleClock 的周期计数单次测量仅约 15~20ns适用于快速函数调用树语义嵌套 span 自动形成调用树路径等价于调用栈可还原真实的执行结构低竞争并发设计线程局部 shard 原子计数器 少量共享锁兼顾热路径性能与导出安全。使用时的前提与限制需要明确必须以--use-tracing-profileron重新构建 mongod否则宏为 no-op需要mongosh在 PATH 中netNanos/exclusiveNanos依赖校准的开销估算存在一定误差README 已注明产物仅覆盖开发者显式插桩的 span不会自动捕获未标注的代码路径。对于定位哪个函数占用了多少时间、被调用了多少次、自身与子树开销如何这类问题它是在 mongod 内部即可完成、无需停机附加外部剖析器的实用方案。相关源码与资源索引关联文档README.md公开接口与宏定义profiler.h核心实现调用树、聚合、serverStatus 导出profiler_internal.cpp内部数据结构与线程分片profiler_internal.h周期时钟封装cycleclock.h单元测试profiler_test.cppGolden 输出样例profiler_service_simple.txt采集脚本profile_mongod.py格式化脚本profile_format.py数据处理库profilerlib.py性能基准profiler_bm.cpp构建定义BUILD.bazel【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考