企业官网建设流程全解析

做AI Infra的同学应该都有过这种体验：一张高配GPU卡跑训练，nvidia-smi一看利用率只有40%，任务没报错，日志里只有零星的“Epoch 2 took 17.3s”。你怀疑是数据加载慢，又怀疑是CPU调度抖动，还怀疑是锁竞争，但手上只有日志和GPU利用率曲线，根本问不出答案。我这几年的处理方式很固定：直接上Perfetto，Google开源的全链路系统性能追踪与剖析平台，把它拉到Linux服务器上，把系统的每个线程在每一毫秒里干了什么录下来，再结合自带的SQL分析引擎，把瓶颈坐标精确到具体进程、具体线程、具体时间片。这篇指南就是我在这类AI训练和推理服务排障场景里总结出来的Perfetto使用经验，适合AI Infra、MLOps、底层性能优化工程师，也适合所有想把服务做到“哪里慢点哪里”的开发同学。

Perfetto的功能边界比很多人理解的要大得多。它不只是Android性能分析工具，在Linux服务器上同样强大；它也不只是抓个CPU调度，还能把内存、磁盘I/O、CPU频率、进程生命周期、用户态自定义打点全部纳入同一条时间线。对AI Infra来说，这正好补上了GPU之外的系统侧视野。下面从原理到实操，按我实际排查问题的顺序完整拆一遍。

1. AI Infra 性能排查为什么绕不开 Perfetto

1.1 训练慢的问题从来不在表面

AI训练和推理的性能瓶颈，绝大多数时候是个“冰山模型”。表面上你看到的是GPU利用率不达标，这是水面上的结果；真正的原因在水面之下：DataLoader线程卡在磁盘I/O上、CPU调度器把关键线程踢出了核、内存带宽被其他进程争抢、某个全局锁把多线程死死的摁住。这层水下问题有个共同特点：它们都发生在操作系统层面，而且都是瞬时状态，普通监控工具根本捕捉不到。

Perfetto能把这些过程完整记录下来。它能让每个CPU核心在任意时刻跑的是哪个线程、线程处于Running还是Runnable还是Sleeping、被谁唤醒、在等什么锁、占了多少CPU频率。拿到这些信息之后，你会发现自己对系统的理解从“盲人摸象”变成“看监控回放”。

顺带说一句，nvidia-smi显示的利用率只是GPU的宏观快照，它不会告诉你GPU kernel与kernel之间的空窗期里，CPU到底在干什么。Perfetto才是那个能回答“CPU那段时间在干什么”的工具。

1.2 和 nvidia-smi / Nsight / py-spy 配合时的定位差异

我用Perfetto不是要替代其他工具，而是让它们形成互补。先放一张我常用的工具分工对照表：

定位问题时的顺序一般是：先用Py-spy看Python线程栈方向，再用Nsight看GPU kernel本身有没有问题，如果GPU kernel栈里没毛病、外部依赖也都正常，那剩下的几乎只有系统调度和资源争抢这一类问题，这时Perfetto就是最合适的下一站。

举个例子：之前排查多卡训练时，GPU利用率只有45%，Nsight显示GPU kernel之间有大段空窗。把Perfetto时间线拉出来一看，所有CUDA kernel的launch线程都处于Runnable状态，但并没有在CPU上运行，它们在等待一个高优先级后台任务释放CPU核心。这种问题不用Perfetto，光靠日志你永远猜不到。

1.3 一个典型场景：GPU 利用率上不去的真相

具体展开一下我遇到的经典案例。某次训练任务，GPU利用率在40%-60%之间剧烈抖动，日志里epoch耗时偶尔会翻倍。第一步我用perfetto抓了30秒时间窗，开的是sched、freq加block三类事件。在UI里放大一个抖动区间，能看到很清晰的模式：某个DataLoader worker线程被调度器频繁踢出CPU，每次被踢后要等几百微秒才能重新上核，而GPU kernel就在这个窗口里空转等待数据。

再把SQL一发，统计了这个worker线程的总Running时间和被抢占频率，数据比肉眼更直观：该线程有近20%的时间处于Runnable但没在运行。顺藤摸瓜找到抢占它的源头，是一个跟训练无直接关系的日志采集进程，把它的CPU优先级调低之后，GPU利用率直接上升到85%以上。

这种场景就是Perfetto在AI Infra里最典型的价值：当GPU在等数据、数据在等CPU、CPU在等调度，它能帮你把这条“等待链”完整画出来。

2. Perfetto 的核心设计：Trace 是怎么录下来的

2.1 底层数据源：ftrace、perf_event、用户态打点

Perfetto本身不是单一技术，而是一个“事件采集和汇总框架”。它把多种底层数据源汇聚到同一条时间线上，我在AI场景里最常用的是三类：

第一类是内核的ftrace事件。Linux内核自带一组静态追踪点，比如sched_switch记录CPU上线程切换、sched_wakeup记录线程被谁唤醒、block_rq_insert记录I/O请求入队、cpu_frequency记录CPU频率变化。这些事件就是Perfetto时间线最核心的语义基础。它不需要改动内核，只要有权限读取tracefs就能采集。

第二类是perf_event硬件计数器。通过内核的perf子系统和CPU性能计数器单元，可以拿到IPC（每周期指令数）、缓存命中率、分支预测失败等数据。这类数据对分析计算密度低、内存访问效率差的训练代码很有帮助。缺点是事件量比较大，需要在采集配置里控制好采样率，否则会撑爆缓冲区。

第三类是用户态打点。Perfetto支持ATrace接口和Perfetto SDK，你可以在自己的训练框架里加自定义标签，比如“DataLoader.load_batch前”“optimizer.step后”，这类事件会跟内核事件精确混排在同一条时间线上。AI框架接入自定义打点后，你能非常直观地看到“GPU在等数据”还是“CPU在等锁”。

2.2 环形缓冲区和配置式采集

Perfetto采集有一个容易忽略但非常重要的设计：它把所有事件写入环形缓冲区，而不是直接落盘。这样做的好处是副作用可控，录制不阻塞业务进程，采样结束后再统一把缓冲内容导出成文件。就算某个瞬间事件风暴很大，最多只是覆盖旧的trace数据，不会拖垮生产任务。

我在生产环境里用Perfetto抓偶发卡顿，推荐的做法是开一个较小的后台采集，事件类别只开关键的几项。持续采集场景下Perfetto的开销极低，基本可以忽略，但换来的是随时能回溯几十分钟内的系统现场。这种“案发现场回放”能力，对AI Infra的稳定性排查太重要了。

采集配置统一写在pbtxt文本文件里，指定用哪些数据源、缓冲多大、要采多久、丢事件时是丢弃新事件还是保留旧事件。这种配置化设计让同一套录制脚本可以在团队内共享复用，不同机器上只需要微调权限和路径。

2.3 Trace Processor：把时间线变成能 SQL 查询的表

很多人用Perfetto只打开UI看时间线，其实它真正的杀手锏是Trace Processor。这个组件会把.perfetto-trace文件里的所有事件解析成一组关系型数据库表，然后你就可以用标准SQL去做查询和聚合。

打个比方：UI是看整个城市的交通监控录像，SQL是直接查数据库，“哪些路口堵塞超过5分钟”。前者适合人眼观察，后者适合机器分析和写归因脚本。比如我要在好几万个blocked事件里找出单个线程最长的一次I/O等待，人眼翻时间线能翻到头秃，SQL一条语句就能算出来。

由于Perfetto的这个设计，trace文件不只是“能看的时间线”，更是“可查询的数据集”。这也是我敢在线上大规模使用它的原因：异常发生后，我能用一个统一的trace文件回答不同团队的各种问题，而不必反复重新采集。

3. 实操：下载安装与一次完整录制

3.1 从哪里拿工具：Perfetto下载与安装

Perfetto的发布包通常从GitHub官方仓库的Releases页面获取，搜索“perfetto下载”也能找到对应地址。里面有几个常用二进制：tracebox是无依赖的采集工具，会自动拉起后台服务并完成录制；perfetto是需要配合traced和traced_probes服务使用的命令行客户端；trace_processor_shell是本地SQL分析工具，我几乎每次都带着它。

把对应的Linux压缩包下载解压后，放到/usr/local/bin或~/bin即可，不需要安装任何依赖。建议直接下载官方release的zip包，因为它已经带了所需的全部动态库，避免在部分精简的AI服务器上出现缺库问题。

以x86_64服务器为例：

wget https://github.com/google/perfetto/releases/download/v46.0/tracebox chmod +x tracebox ./tracebox --version

如果你的服务器需要给容器内的进程做性能分析，建议在宿主机上运行Perfetto，因为它需要直接读内核tracefs和procfs，容器内权限经常会受限。

3.2 权限检查与内核条件

Perfetto采集内核事件需要root权限，或者具备CAP_SYS_ADMIN能力。在绝大多数AI训练服务器上，直接使用sudo来运行采集命令是最省事的。运行前建议先确认tracefs挂载位置和权限：

mount | grep tracefs ls -l /sys/kernel/tracing

如果路径下没有tracing_on这类文件，可能是tracefs没挂载，需要手动挂载或者让内核模块正常加载。部分云主机的内核默认没开启ftrace配置，这种情况需要换用标准内核镜像才能用上sched、block事件。

手机端Android上使用Perfetto是另一个常见路径，通过adb shell perfetto即可，权限由adb统一处理，基本不用操心。这部分对做端侧AI服务的同学比较友好。

3.3 录制一条完整的 trace：命令行与配置

我习惯把配置写到文件里，方便版本管理。一份面向AI训练场景的基础配置大概长这样：

# /tmp/train_config.pbtxt buffers { size_kb: 65536 fill_policy: DISCARD } data_sources { config { name: "linux.ftrace" ftrace_config { ftrace_events: "sched/sched_switch" ftrace_events: "sched/sched_wakeup" ftrace_events: "power/cpu_frequency" ftrace_events: "block/block_rq_insert" ftrace_events: "block/block_rq_complete" ftrace_events: "kmem/kmalloc" ftrace_events: "kmem/kfree" } } } data_sources { config { name: "linux.process_stats" target_buffer: 0 } } duration_ms: 30000

这个配置的意思是：30秒时间窗，64MB环形缓冲，捕获取向调度、CPU频率变化、块设备I/O请求、内存分配释放，以及各进程的CPU/内存统计。对于AI场景，这组事件的“性价比”非常高，既能回答“谁抢了CPU”“谁在等磁盘”，又不会因为数据量过大把缓冲撑爆。

执行录制：

sudo ./perfetto -o /tmp/train_trace.perfetto-trace -c /tmp/train_config.pbtxt

录制结束后会生成.perfetto-trace文件。你也可以用tracebox一行命令快速抓取，适合临时采样：

sudo ./tracebox -o /tmp/quick_trace.perfetto-trace -t 20s sched freq idle

这里的sched、freq、idle是便捷别名。如果遇到线上环境没法常驻采集服务的情况，tracebox比perfetto命令更顺手，因为它会自动拉起和停止后台服务，不污染环境。

3.4 分析：Perfetto 的 UI 与本地 SQL

拿到trace文件后，最直观的分析方式是打开官方Perfetto UI，也就是ui.perfetto.dev，把.perfetto-trace文件拖进去就行。UI左侧是各CPU核心的时间线，每一条彩色条带表示一个线程运行片段，下方是各进程的线程状态、频率变化和I/O事件。

如果是例行化的问题排查，我更推荐直接用trace_processor_shell做本地查询。它支持非交互式查询模式，适合写进自动化脚本：

./trace_processor_shell --query "SELECT utid, SUM(dur) AS total_running FROM sched GROUP BY utid ORDER BY total_running DESC LIMIT 10" /tmp/train_trace.perfetto-trace

这条SQL能快速输出CPU占用时间最长的前10个线程。结合线程名，可以立刻判断是不是某个DataLoader线程或者某个后台进程在吃CPU。UI就是看全貌，SQL就是找答案，两者配合是最优解。

4. AI Infra 场景中的操作要点与进阶玩法

4.1 抓哪些事件才能回答“GPU 为什么饿”

Perfetto有一个天然短板：它不直接采集NVIDIA GPU的kernel执行事件，所以你不能指望它告诉你某个CUDA kernel运行了多久。要回答“GPU为什么饿”，需要把系统侧的事件范围收窄到能间接表示GPU饥饿的维度上，也就是数据供给链上的事件。

我的建议是在AI场景下优先开启以下事件组合：

不推荐在首轮分析时就全量开启所有ftrace事件。事件种类一多，缓冲区容易溢出，最后你会发现关键的sched_switch反而被挤掉了。先开最小集，找到嫌疑方向，再针对性地加特定事件类别，这是我自己实践下来的最优策略。

4.2 给训练代码加自定义打点

AI Infra的很多瓶颈藏在业务代码和系统调度的交界处。比如你想知道“从数据就绪到GPU kernel启动”之间到底发生了什么，单靠操作系统事件是看不全的，因为中间有你的训练循环逻辑。

这时可以用Perfetto的用户态打点能力。最轻量的方式是往/sys/kernel/tracing/trace_marker写字符串：

echo "dataloader_start" > /sys/kernel/tracing/trace_marker

在训练代码里围绕关键阶段插入标记，录制后这些字符串会精确出现在时间线上。更正式的做法是接入Perfetto SDK，用C++或Java在自己的组件里添加自定义事件，支持打点、线程状态、计数器和自定义数据表。

我之前做推理服务优化时，就在请求处理的关键路径上打了几个标记：请求到达、预处理完成、模型推理开始、推理结束。通过Perfetto时间线可以非常清晰地看到，大部分时间消耗在“排队等GPU”和“预处理同步等待”上，而不是模型算子本身。这种信息对优化方向的指导价值极大。

4.3 TraceProcessor SQL 分析模板

SQL能力是Perfetto高效用的关键。我把自己常用的几个分析模板直接放这里，可以当成通用工具箱使用。

模板一：统计指定线程的真实运行时间占比。

SELECT t.name AS thread_name, p.name AS process_name, SUM(s.dur) / 1000000 AS running_ms FROM sched s JOIN thread t ON s.utid = t.utid LEFT JOIN process p ON t.upid = p.upid WHERE t.name GLOB '*DataLoader*' GROUP BY t.utid ORDER BY running_ms DESC;

这条SQL专门用来判断DataLoader线程到底在不在干活。如果Running时间很少，但线程又一直存在，说明它要么在等I/O，要么在等锁。

模板二：找出长时间阻塞在I/O等待上的线程。

SELECT t.name AS thread_name, COUNT(DISTINCT s.id) AS io_wait_count, SUM(CASE WHEN s.thread_state = 'D' THEN 1 ELSE 0 END) AS uninterruptible_count FROM sched s JOIN thread t ON s.utid = t.utid GROUP BY t.utid ORDER BY io_wait_count DESC LIMIT 20;

D状态指的是不可中断睡眠，常见场景是磁盘I/O等待。如果某个线程的D次数异常多，磁盘基本可以判定为瓶颈。

模板三：按进程统计总运行时间。

SELECT p.name AS process_name, SUM(s.dur) / 1e9 AS total_running_sec FROM sched s JOIN process p ON s.upid = p.upid GROUP BY s.upid ORDER BY total_running_sec DESC;

这条SQL非常适合快速排查“到底谁在吃CPU”，尤其在多进程互相干扰的训练服务器上，往往一个辅助进程就能吃掉大量CPU资源。

4.4 长时间后台录制与脱机收集

线上偶发问题的排查难点不是“抓到以后怎么分析”，而是“问题出现时抓不抓得到现场”。Perfetto支持后台常驻录制，也是我用它做AI Infra稳定性保障时最看重的功能。

用--background参数可以让采集在后台运行，不占用当前终端：

sudo ./perfetto --background -o /tmp/trace_bg.perfetto-trace -c /tmp/bg_config.pbtxt

后台模式下需要提前把duration_ms设置成比较大的值，或者用循环录制。我在生产服务器上常用的做法是60秒一个文件，循环保存最近若干个文件，一旦线上出现异常就能留存完整的现场trace。这样不用问题时手忙脚乱地开始抓包，而是在事发后直接从磁盘恢复分析，效率和体验都会好很多。

需要注意后台录制的磁盘占用。60秒的trace在只开基础事件时约50-100MB，长时间保留要多留一些磁盘余量。建议在配置里只开必要事件，用容量换时间。

5. 常见问题与避坑实录

5.1 问题排查速查表

这里特别提一句：Perfetto不是万能的。如果你要深入分析kernel内部耗时，比如某个GPU算子为什么执行得慢，那是Nsight的领域；Perfetto的强项始终是系统级调度、I/O、资源争抢这条线，两者并不冲突，结合使用效果最好。

5.2 我踩过的几个坑与对应策略

第一个坑是“贪多嚼不烂”。刚开始用Perfetto时，我喜欢把所有数据源全部打开，觉得多抓一点保险。结果录制到一半缓冲区溢出，最关键的sched_switch事件被覆盖，那段时间线全是空洞。之后我学乖了，首轮只抓最基础的三个类别，定位到嫌疑目标后再针对性地增加事件。

第二个坑是“只看UI不跑SQL”。时间线视图虽然直观，但面对几千个线程的服务，人眼根本没法汇总规律。真正高效率的做法是把trace文件丢给trace_processor_shell，用SQL把关键指标跑出来。我现在几乎不会只靠肉眼盯时间线做排查，那只是辅助验证手段。

第三个坑是“窗口选错了”。问题出现在下午2点，我等到2点10分才开始录制，现场早就过去了。后来我养成了在关键训练任务或推理服务上常驻后台录制的习惯，把trace文件循环留存，这样任何异常都有据可查。代价只是一点磁盘空间和极低的CPU占用，换来的是问题发生后的完整现场。

第四个坑比较隐蔽：多机训练场景下，不同机器的系统时间如果不一致，trace里的事件对不齐。Perfetto虽然支持boot clock，但默认可能使用的是wall clock。多机对比分析时，建议在录制脚本里显式指定时钟源，保证同一批次机器的时间基准一致。

5.3 从“会用”到“用好”的进阶经验

如果你已经能熟练采集并分析trace，下一步我建议往自动化方向走。Perfetto的SQL接口非常适合做回归检测：比如定期在训练集群上录制一小段trace，用SQL把几个核心指标（CPU平均负载、最长调度延迟、DataLoader总Running时间占比）记录下来，对比历史数据可以发现性能劣化趋势。

我们团队现在有一套简单的定时任务，每天对重点训练任务做一次90秒的定向录制，然后自动执行一组SQL查询，把结果追加到指标表。训练任务发布新版本后，如果某些关键指标出现明显变化，就会自动触发告警。这套体系上线之后，很多性能回退都在用户反馈之前就被发现了。

这个方向也适合做精细化的容量规划。很多AI Infra团队只关注GPU利用率，但系统侧的CPU调度余量、内存带宽余量、I/O队列深度其实更能反映真实瓶颈。Perfetto的trace文件就是这些底数的最好来源。我现在做容量评估时，都会要求相关团队先提供一份典型高负载时段的trace，用SQL算出详细数据，再决定扩容方案和减负方案。

如果你准备在团队里推广Perfetto，我的建议是先从一个真实的疑难问题入手，把这个案例完整走通，把方法沉淀成文档和SQL模板，再复制到其他场景。工具本身学习曲线不算陡，但价值认可需要靠实打实的案例来建立。这也是整个AI Infra工作的一般规律：不追求用遍所有工具，而是把少数几个核心工具用到极致，让它们帮你真正解决问题。