📚 课程目录第3章 Trace数据采集策略

3. Trace 数据采集策略：区分进程级别、CPU核心级别、时间段选择、内存计数器启用

3.1 现象识别：数据不足与噪声干扰

在进行缓存瓶颈分析时，最常见的错误并非分析工具使用不当，而是采集的数据无法支撑定位。典型症状表现为：Trace 文件中缺乏高频事件的采样点、关键缓存未命中计数器为 0、或 CPU 频率与指令流完全无法对齐。这些现象的根因通常是采集策略不当，例如未启用特定内存计数器、采样范围过广导致缓冲区溢出、或错误的时间窗设置引入了大量无关进程。

3.2 数据采集：配置正确的 Trace 会话

为精准定位缓存瓶颈，数据采集必须从“全量捕获”转向“定向狙击”。本阶段的核心在于通过 Perfetto 的 Trace Config 精确控制采集范围，避免数据过载和关键信息丢失。

3.2.1 进程级别过滤

使用 buffers 和 data_sources 中的 target_buffer 配合 FtraceConfig 的 filter 字段，或更高效的 TrackEventConfig 的 enabled_tags。对于缓存问题分析，通常只追踪目标进程及其关键子线程。

# 示例 trace config 片段 (仅进程过滤部分)
data_sources {
    config {
        name: "linux.ftrace"
        ftrace_config {
            # 仅跟踪指定 PID 的调度和 CPU 频率事件
            scan_pids_on_start: true
            filter_pids: [12345, 12346]  # 目标进程及其关键渲染线程
        }
    }
}

3.2.2 CPU 核心级别聚焦

对于 NUMA 架构或大小核处理器，跨核迁移会导致大量缓存一致性流量。若怀疑是特定 CPU 集群（如大核集群）内的缓存问题，可将采集范围限制在该集群对应的 CPU 核心上。

# 示例 trace config 片段 (CPU 核心过滤)
data_sources {
    config {
        name: "linux.ftrace"
        ftrace_config {
            # 仅采集 CPU 0-3 的事件（假设为性能核集群）
            # 在 Perfetto UI 中通过 atrace 或直接修改 config 实现
            # 注意：ftrace 支持 per_cpu 缓冲区，但此配置需结合系统能力
            # 另一种方式：在启动 trace 时通过 taskset 绑定 perfetto 进程
        }
    }
}

误区警示：不要将进程过滤与 CPU 核心过滤混淆。进程过滤减少无关事件量，而 CPU 过滤减少跨核同步带来的缓冲区负担。两者结合使用时，需要确保目标进程的调度域与被过滤的核心集有交集。

3.2.3 时间段选择策略

避免采集整个应用生命周期的 Trace，而是使用“环形缓冲区”模式，或通过 trigger 配置在特定性能计数器阈值触发时自动写入文件。

# 使用 trigger 启动 trace 写入（时间窗精准截取）
triggers {
    name: "trigger.cache_misses"
    # 当 PERF_COUNT_HW_CACHE_MISSES 超过 10% 时触发dump
    # 注：此示例需配合 perf 数据源
    stop_delay_ms: 200  # 触发后继续采集 200ms 用于捕获后续行为
}

3.2.4 内存计数器的启用

这是分析缓存瓶颈最关键的一步。必须启用 Perfetto 的 memfd 或 sys.stats 数据源，并确保内核跟踪点 memory_busy 或 cache_access 已开启。对于 Arm 架构，需要确认 PMU 事件中的 L1D_CACHE_REFILL、L2D_CACHE_REFILL 等计数器是否可用。

# 启用内存计数器 (trace config 示例)
data_sources {
    config {
        name: "linux.sys_stats"
        sys_stats_config {
            meminfo_period_ms: 100
            vmstat_period_ms: 100
            # 关键：启用 page cache 和 slab 跟踪
            stat_period_ms: 100
        }
    }
}
# 必须同时启用 ftrace 中的 memory 相关事件
data_sources {
    config {
        name: "linux.ftrace"
        ftrace_config {
            # 启用所有内存事件
            tracefs_events: "kmem/*"
            tracefs_events: "mem/*"      # 包含 cache_alloc, cache_free
            tracefs_events: "mm_filemap/*" # 包含 page_cache 操作
        }
    }
}

关键指标检查：采集完成后，立即在 Perfetto UI 中验证“Memory”标签页是否有数据。若 L1-dcache-load-misses 或 LLC-load-misses 曲线为全零，且 dmidecode 确认硬件支持，则说明采集配置有误。

3.3 排查表：采集配置检查清单

检查项	正常状态	异常状态与处理
目标进程 PID 过滤	Trace 仅包含 <10 个活跃进程	若包含 100+ 进程，缩小过滤范围
CPU 核心子集选择	仅包含目标集群核心	若包含所有核心，须增大 buffer 至 256MB+
内存计数器使能	`perf stat -e cache-misses` 有非零值	确认 Linux 内核版本 ≥5.10 且 config 中未遗漏
缓冲区大小	Trace 文件 < 500MB（典型 60s 采集）	若文件 >2GB，缩短采集时长或增大 buffer
环形缓冲区 / trigger 使用	已配置 stop_delay_ms	未配置时，务必手动触发 dump 时机

3.4 内联 SVG 图：Trace 数据采集策略流程图

3.5 判断规则：采集是否成功

规则1：计数器有效性 — 在 Perfetto UI 中搜索“cache-misses”，若出现连续非零值且随代码阶段波动，标记为采集成功。
规则2：时间对齐 — 检查 CPU 频率曲线与 cache-misses 曲线的峰值是否在 ±1μs 内对齐。若不对齐，说明时间同步有偏差，需启用 clock_sync。
规则3：缓冲区未溢出 — 查看 trace 文件大小。若超过分配的 buffer 大小（如 256MB 的 80% 以上），会出现丢弃事件，此时必须缩短采集时长或增大 buffer。

3.6 典型案例：因未启用内存计数器导致的误判

现象：某游戏团队发现首帧渲染卡顿，Trace 中显示 CPU 频繁空闲，但找不到任何 I/O 或锁等待。怀疑是缓存问题，但所有 cache-miss 计数器均为 0。

采集配置修复：修改 Trace Config，在 ftrace_config 中加入 tracefs_events: "kmem/*" 并确认内核支持 CONFIG_MEMCG_KMEM。重新采集后，L1-dcache-load-misses 显示峰值达到 40%，与卡顿帧完美对齐。最终定位是 std::unordered_map 的桶链表过长导致。

3.7 修复动作与复测验证

一旦确认采集策略正确，后续原因定位和修复才能建立在高置信度的数据基础上。若修复后 Trace 中 cache-misses 降低但仍高于基线，重复“启用内存计数器→限定进程→分析热点→修改代码”的循环。

3.8 预防：建立采集 SOP

在 CI/CD 中集成 Perfetto 采集脚本，自动校验内存计数器返回值。
为每个性能版本创建基线 Trace 配置文件，包含已知的有效 ftrace_events 集合。
定期更新内核跟踪点列表，确保新硬件特性（如 Arm SPIN 或 Intel RDT）对应的计数器被及时纳入。