3. 性能瓶颈分析：推流性能关键指标与Profiling工具实战
推流性能优化，说白了就是跟三个数字较劲：FPS、码率、延迟。这三个指标互相牵制，你压了这头那头就翘起来。我刚开始做RTSP推流时，就吃过这个三角关系的亏——只顾着拉高FPS，结果延迟飙到没法看。
这一章，咱们就聊聊怎么识别瓶颈、怎么用工具定位问题。嗯，先看一张整体知识图，心里有个谱。
3.1 推流性能的三个核心指标
先搞清楚我们要测量什么。这三个指标，每个都有坑。
3.1.1 FPS（帧率）
FPS就是每秒编码并推出去的帧数。理论上越高越流畅，但实际中我见过太多人盲目追求60fps，结果CPU跑满、编码队列堆积，反而导致画面卡顿。
3.1.2 码率（Bitrate）
码率决定了画面质量。但码率不是越高越好——你想想看，网络带宽是固定的，码率设太高，缓冲区就满了，延迟跟着涨。
我习惯把码率分成三档来测：
- 固定码率（CBR）：适合带宽受限场景，但画面复杂时质量会崩
- 可变码率（VBR）：质量稳定，但码率波动大，可能撑爆网络
- 自适应码率（ABR）：折中方案，我项目里用得最多
3.1.3 延迟（Latency）
延迟是从摄像头采集到客户端显示的时间差。很多人只关注网络延迟，其实编码延迟、缓冲延迟往往更大。
3.2 常见瓶颈点识别
瓶颈不会自己跳出来告诉你。你得知道去哪找。我总结了三个最常见的重灾区：
3.2.1 CPU编码瓶颈
这是最普遍的。软件编码器（x264、x265）吃CPU吃得厉害。怎么判断？看CPU使用率是不是持续100%，或者编码队列是不是一直在增长。
我遇到过最典型的情况：一台4核服务器，跑4路1080p推流，CPU直接打满。后来换成硬件编码（NVENC），CPU降到30%，同样的机器能跑12路。
| 编码方式 | CPU占用 | 画质 | 适用场景 |
|---|---|---|---|
| 软件编码（x264） | 高（80-100%） | 优秀 | 画质优先，资源充足 |
| 硬件编码（NVENC/VAAPI） | 低（10-30%） | 良好 | 高并发，资源受限 |
| GPU加速编码 | 中（40-60%） | 良好 | 平衡方案 |
3.2.2 网络带宽瓶颈
网络瓶颈的表现很直接：丢包、重传、RTT飙升。但有个坑——你以为带宽够，实际上路由器或交换机端口可能已经满了。
我记得有一次排查一个客户的推流卡顿问题，服务器带宽监控显示只有50Mbps，但客户说拉了200M专线。最后发现是交换机端口协商成了100M半双工。嗯，这种硬件层面的坑，光看软件指标是看不出来的。
3.2.3 内存与IO瓶颈
内存瓶颈往往被忽略。推流过程中，每一帧都要经过“采集→编码→封装→发送”这条流水线。如果内存分配频繁、或者磁盘IO（比如写本地录像）拖后腿，整个流水线都会卡住。
3.3 Profiling工具使用实战
工具是工程师的眼睛。下面这三个工具，我几乎每天都会用到。
3.3.1 perf：采样分析利器
perf是Linux内核自带的性能分析工具，开销极低。它通过采样CPU的PC指针，告诉你程序的时间花在哪了。
基本用法：
# 采样30秒
perf record -g -p <pid> -- sleep 30
# 生成火焰图
perf script | stackcollapse-perf.pl | flamegraph.pl > perf.svg我习惯先跑一次perf，看看热点函数在哪。如果发现编码函数占了80%以上的CPU时间，那瓶颈就很明确了。
3.3.2 gprof：函数级调用分析
gprof需要编译时加-pg选项，运行后会生成gmon.out文件。它能告诉你每个函数被调用了多少次、每次耗时多少。
用法：
# 编译
gcc -pg -o rtsp_pusher rtsp_pusher.c
# 运行
./rtsp_pusher
# 分析
gprof rtsp_pusher gmon.out > analysis.txtgprof的缺点是插桩开销较大，会影响性能数据。我一般只在开发环境用，生产环境用perf。
3.3.3 Valgrind：内存问题侦探
Valgrind的callgrind工具可以做函数级分析，但它的强项是内存检查。对于推流这种高频内存操作的程序，内存泄漏和越界是常见问题。
常用命令：
# 内存泄漏检查
valgrind --leak-check=full ./rtsp_pusher
# 性能分析（callgrind）
valgrind --tool=callgrind ./rtsp_pusher3.4 实战：一次完整的瓶颈定位流程
光说不练假把式。我拿一个真实案例来演示：
- 现象： 1080p推流，FPS只有15，目标25。
- 第一步：perf top → 发现libx264编码函数占CPU 75%。
- 第二步：检查编码参数 → preset设为"placebo"，这是最慢的档位。
- 第三步：改成"medium" → CPU降到40%，FPS升到24。
- 第四步：Valgrind检查 → 发现一处帧缓冲区未释放，导致内存持续增长。
- 第五步：修复内存泄漏 → 运行24小时，内存稳定在200MB。
你看，整个过程不到半小时。工具用对了，问题就藏不住。