Linux性能分析实战：用trace揪出卡顿、高CPU的“真凶”

 

 

做 Linux 开发或运维的你，是否常被这些问题困扰：服务突然卡顿却找不到根源，CPU 占用率飙升但查不到 “罪魁祸首”，系统响应变慢却摸不清瓶颈？其实，Linux 内核早已为我们准备了 “透视镜”——trace 跟踪技术，今天就手把手教你从生成 trace 文件到可视化分析，搞定性能难题！

 

 

 

一、先搞懂：trace 分析的核心工具

 

在开始实操前，我们先理清几个关键工具的作用，避免“知其然不知其所以然”：

 

 

•debugfs/tracefs：Linux 内核提供的调试文件系统，是 trace 分析的 “基础设施”。debugfs 用于暴露内核调试信息，tracefs 专门记录内核 / 应用的事件（如 CPU 调度、系统调用），后续工具都依赖这两个文件系统。

 

 

•atrace：Android 团队推出的跟踪工具（也适用于 Linux），能收集内核事件（sched 调度、syscalls 系统调用）和应用活动（如线程状态），生成原始 trace 文件。

 

 

•catapult：Google 开源的性能分析套件，其中trace2html工具能将原始 trace 文件转成交互式 HTML 报告，让我们用可视化方式快速定位问题。

 

 

•adb：跨设备传输工具，当我们在嵌入式 Linux（如开发板）或 Android 设备上分析时，用它实现本地电脑与目标设备的文件传输。

 

 

二、手把手实操：从 0 生成 trace 分析报告

 

接下来我们以“分析某 Linux 服务卡顿” 为例，按步骤完成整个流程，所有命令都已标注细节，新手也能跟着做！

 

 

步骤 1：检查核心文件系统是否挂载

 

首先要确认debugfs和tracefs已挂载—— 这是后续操作的前提，没挂载的话工具会 “罢工”。

 

 

在目标 Linux 设备（或通过 adb 连接的远程设备）上执行：

 

 

# 检查debugfs是否挂载     mount | grep debugfs     # 检查tracefs是否挂载     mount | grep trace

关键补充：

 

•如果执行后无输出（文件系统未挂载），手动挂载（需 root 权限）：

 

 

# 挂载debugfs到默认路径     mount -t debugfs debugfs /sys/kernel/debug     # 挂载tracefs到默认路径     mount -t tracefs tracefs /sys/kernel/tracing

•不同 Linux 发行版路径可能有差异（如部分嵌入式设备是/debug），可通过find / -name debugfs查找实际路径。

 

 

步骤 2：上传工具到目标设备

 

我们需要将两个关键文件传到目标设备：atrace.sh（封装 atrace 命令的脚本，简化参数配置）和catapult-main.zip（可视化工具包）。

 

 

在本地电脑（Windows 为例）打开命令行，执行 adb 传输命令：

 

 

# 1. 上传atrace.sh脚本到目标设备的根目录（/）     adb push C:Usersmdg_rDesktoppullatrace.sh /     # 2. 上传catapult工具压缩包到根目录     adb push C:Usersmdg_rDesktoppullcatapult-main.zip /     # 3. 给atrace.sh添加可执行权限（Linux文件默认无执行权）     adb shell chmod 777 /atrace.sh

小知识：

 

•chmod 777表示所有用户（所有者、组、其他）都有读、写、执行权限，测试环境用很方便；生产环境建议缩小权限（如chmod 700，仅所有者可执行）。

 

 

•如果目标设备不是 Android（如 Ubuntu 服务器），无需用 adb，直接用scp传输文件：scp C:xxxatrace.sh user@服务器IP:/。

 

 

步骤 3：生成原始 trace 文件

 

执行atrace.sh脚本，收集系统运行数据。脚本参数my_trace是输出文件名，3表示跟踪 3 秒（根据需求调整，建议 1-5 秒，避免文件过大）。

 

 

在目标设备上执行：

 

 

# 进入根目录     cd /     # 运行脚本，跟踪3秒，输出到my_trace文件     ./atrace.sh my_trace 3

深入理解：

 

•atrace.sh本质是封装了atrace命令，你也可以直接用原生命令自定义跟踪内容，比如只跟踪 CPU 调度和系统调用：

 

 

# 原生atrace命令：跟踪sched（调度）、syscalls（系统调用），持续3秒     atrace --set_events sched,syscalls -o my_trace 3

•常见跟踪事件类型：sched（CPU 调度）、gfx（图形渲染，适合 UI 场景）、disk（磁盘 I/O）、mem（内存活动），根据性能问题类型选择。

 

 

步骤 4：将 trace 文件转成可视化 HTML

 

原始 trace 文件是纯文本，几百行甚至几十万行数据，直接看根本看不懂 —— 这时候catapult的trace2html就派上用场了，能把数据转成带时间轴的交互式报告。

 

 

先解压 catapult 工具包，再执行转换命令：

 

 

# 1. 解压catapult压缩包（如果已解压可跳过）     unzip catapult-main.zip     # 2. 执行trace2html，生成HTML报告     ./catapult-main/tracing/bin/trace2html --config chrome --output my_trace.html my_trace

关键说明：

 

•--config chrome表示按 Chrome 浏览器的报告格式生成（最常用，支持丰富的视图）；

 

 

•执行后会生成my_trace.html文件，这个就是我们最终要分析的“性能报告”。

 

 

步骤 5：拉取报告到本地分析

 

目标设备（如开发板）可能没有浏览器，把 HTML 文件拉回本地电脑，用 Chrome、Edge 等浏览器打开分析。

 

 

在本地电脑执行 adb 拉取命令：

 

 

adb pull /my_trace.html C:Usersmdg_rDesktoppull

至此，我们就完成了从“收集数据” 到 “生成报告” 的全流程，接下来就是最核心的 ——分析报告找问题！

 

 

三、核心技巧：怎么从 HTML 报告中揪出性能瓶颈？

 

打开my_trace.html后，主要关注 3 个核心视图，90% 的性能问题都能在这里找到答案：

 

 

1. 时间轴视图（Timeline）：看 “卡顿点”

 

这是最直观的视图，横向是时间（从跟踪开始到结束），纵向分 3 层：

 

 

•CPU 核心层：每个 CPU 核心的运行状态（绿色 = 运行，灰色 = 空闲，橙色 = 中断）；

 

 

•进程层：每个进程的活动时间线；

 

 

•线程层：每个线程的状态（Running = 运行，Waiting = 等待，Sleeping = 休眠）。

 

 

分析方法：

 

•找“异常等待”：如果某个业务线程长时间处于Waiting状态（比如超过 100ms），可能是 CPU 资源不足（被其他进程抢占）或锁竞争（线程等锁）；

 

 

•看“时间断层”：如果整个时间轴突然有一段无活动（灰色），可能是系统调用阻塞（如磁盘 I/O 卡住）。

 

 

2. CPU 占用视图（CPU Usage）：找 “吃 CPU 的进程”

 

这个视图用柱状图或折线图展示每个 CPU 核心的占用率，以及每个进程对 CPU 的消耗占比。

 

 

分析方法：

 

•看“峰值”：如果某进程的 CPU 占用率突然飙升到 90% 以上，且持续时间长，那它很可能是性能瓶颈；

 

 

•看“核心负载均衡”：如果只有 1 个 CPU 核心占用率高，其他核心空闲，可能是进程线程数太少，或存在单线程瓶颈。

 

 

3. 事件详情视图（Event Details）：查 “耗时操作”

 

点击时间轴上的任意事件（如sys_read系统调用、sched_switch调度事件），会弹出详情面板，显示：

 

 

•事件开始 / 结束时间、持续时长；

 

 

•关键参数（如sys_read的文件描述符、读取字节数）；

 

 

•调用栈（如果开启了栈跟踪）。

 

 

分析方法：

 

•找“长耗时事件”：比如sys_write耗时超过 50ms，可能是磁盘写入速度慢；sched_switch频繁，可能是进程切换太频繁（上下文切换开销大）；

 

 

•看“调用栈”：如果某函数调用耗时久，可顺着调用栈定位到具体代码（需配合符号表）。

 

 

四、避坑指南：这些问题别踩！

 

1.trace 有性能开销，生产环境慎用

 

 

跟踪过程会消耗 CPU 和内存（尤其是跟踪事件多、时长久时），生产环境建议：①缩短跟踪时长（1-3 秒）；②只跟踪关键事件（如只跟踪 sched+syscalls）；③避开业务高峰期。

 

 

2.权限不够？先提权！

 

 

挂载 tracefs/debugfs、运行 atrace 都需要 root 权限，执行命令前加sudo（如sudo ./atrace.sh），或切换到 root 用户（su root）。

 

 

3.文件太大打不开？先筛选事件

 

 

如果 trace 文件超过 100MB，HTML 报告可能加载缓慢，建议在生成 trace 时用--set_events筛选事件，比如只跟踪与业务相关的进程：atrace -p 1234（进程ID） -o my_trace 3。

 

 

4.工具兼容性问题

 

 

◦atrace 在非 Android 设备上需安装依赖：Ubuntu/CentOS 可执行sudo apt install android-tools-adb（部分系统需手动编译 atrace）；

 

 

◦catapult 需要 Python 环境（Python 2.7 或 3.x），如果执行trace2html报错，先检查 Python 是否安装：python --version。

 

 

五、总结

 

今天我们用“检查文件系统→上传工具→生成 trace→转 HTML→分析报告” 的流程，完整走了一遍 Linux trace 性能分析。这套方法的核心优势是：

 

 

•底层可见：能看到内核级事件（如调度、系统调用），比top、ps等工具更深入；

 

 

•可视化直观：HTML 报告比纯文本日志更容易定位问题；

 

 

•跨场景适用：嵌入式 Linux、服务器、Android 设备都能用。

 

 

如果你的项目中遇到了特殊的性能问题（比如内存泄漏、网络延迟），或者对 trace 分析有疑问，欢迎在评论区留言！需要atrace.sh脚本模板或 catapult 工具包的朋友，也可以私信我获取～

---