做AI Infra的同学应该都有过这种体验一张高配GPU卡跑训练nvidia-smi一看利用率只有40%任务没报错日志里只有零星的“Epoch 2 took 17.3s”。你怀疑是数据加载慢又怀疑是CPU调度抖动还怀疑是锁竞争但手上只有日志和GPU利用率曲线根本问不出答案。我这几年的处理方式很固定直接上PerfettoGoogle开源的全链路系统性能追踪与剖析平台把它拉到Linux服务器上把系统的每个线程在每一毫秒里干了什么录下来再结合自带的SQL分析引擎把瓶颈坐标精确到具体进程、具体线程、具体时间片。这篇指南就是我在这类AI训练和推理服务排障场景里总结出来的Perfetto使用经验适合AI Infra、MLOps、底层性能优化工程师也适合所有想把服务做到“哪里慢点哪里”的开发同学。Perfetto的功能边界比很多人理解的要大得多。它不只是Android性能分析工具在Linux服务器上同样强大它也不只是抓个CPU调度还能把内存、磁盘I/O、CPU频率、进程生命周期、用户态自定义打点全部纳入同一条时间线。对AI Infra来说这正好补上了GPU之外的系统侧视野。下面从原理到实操按我实际排查问题的顺序完整拆一遍。1. AI Infra 性能排查为什么绕不开 Perfetto1.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不是要替代其他工具而是让它们形成互补。先放一张我常用的工具分工对照表工具能看什么短板nvidia-smiGPU利用率、显存、温度只到秒级整体视图看不出线程级因果NVIDIA Nsight SystemsGPU kernel耗时、CUDA API调用GPU侧很强系统调度层细节少py-spyPython进程内的线程栈拿不到内核调度、I/O、锁等底层事件PerfettoCPU调度、I/O、内存、频率、自定义事件全链路不直接采GPU kernel需配合Nsight或手动打点定位问题时的顺序一般是先用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场景下优先开启以下事件组合事件类别解决的问题sched/sched_switch定位哪个线程在抢CPU训练线程是否被踢出sched/sched_wakeup谁唤醒了等待中的DataLoader线程block/block_rq_insert数据加载是否卡在磁盘I/O队列power/cpu_frequencyCPU是否因为降频导致数据处理变慢kmem/kmalloc内存频繁分配回收导致的锁竞争不推荐在首轮分析时就全量开启所有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 问题排查速查表现象可能原因处理方法trace文件几个GBUI加载卡死缓冲区太大或事件种类开太多降低size_kb从最小事件集开始UI提示buffer overflow事件丢失事件产生速度超过缓冲区增大缓冲区或裁剪数据源提示ftrace权限不足当前用户无root/CAP_SYS_ADMIN使用sudo运行或调整权限内核线程名全是?或地址模糊kptr_restrict限制临时echo 0 /proc/sys/kernel/kptr_restrict看不到用户态代码的自定义标记未启用trace_marker或SDK确认权限和Perfetto SDK正确接入trace里GPU利用率相关数据为空Perfetto不直接采GPU kernel事件配合NVIDIA Nsight或用SDK手动打点多台机器trace时间轴对不上时钟未统一使用boot clock或确保NTP同步这里特别提一句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工作的一般规律不追求用遍所有工具而是把少数几个核心工具用到极致让它们帮你真正解决问题。