3. 性能瓶颈分析概述
好，咱们进入第三章。CPU瓶颈，说白了就是你的CPU忙不过来了。做多媒体流系统，CPU是绝对的核心。我见过太多项目，GPU、网络、存储都调得挺好，结果CPU先扛不住了。这一章，咱们就把CPU这块掰开揉碎了看。
3.1 编解码器CPU占用率：吃CPU的大户
编解码器，尤其是软件编解码器，是CPU消耗的绝对主力。你想想看，一秒钟要处理几十帧图像，每帧图像几百万个像素点，每个像素点还要做变换、量化、熵编码……这计算量，CPU不热才怪。
核心观点：编解码器的CPU占用率，直接决定了系统能同时处理多少路流，以及能支持多高的分辨率与帧率。
我个人习惯，拿到一个系统，第一件事就是看编解码器的CPU占用率。怎么测？用top、htop或者perf top，盯着进程看。但这里有个坑，我踩过好几次。
注意：CPU占用率不是越高越好，也不是越低越好。关键看它是不是“有效占用”。如果CPU占用率很高，但帧率上不去，那说明编解码器效率低，或者有锁竞争、内存拷贝等开销在“空转”。
举个例子，H.264和H.265（HEVC）的CPU消耗差别很大。H.265编码复杂度大约是H.264的2-4倍。我在一个项目中，把编码器从H.264换成H.265，码率降了40%，但CPU占用率直接飙到95%，导致其他模块没时间跑。最后只能降分辨率，或者换硬件编码器。
这里我列个表，方便你快速对比常见编解码器的CPU消耗特点：
| 编解码器 | 编码复杂度 | 解码复杂度 | 典型应用场景 | CPU瓶颈风险 |
|---|---|---|---|---|
| H.264 | 中等 | 低 | 直播、点播、视频会议 | 中等 |
| H.265/HEVC | 高 | 中等 | 4K/8K视频、高码率场景 | 高 |
| VP9 | 高 | 中等 | WebRTC、YouTube | 高 |
| AV1 | 极高 | 高 | 下一代流媒体、超高清 | 极高 |
| AAC | 低 | 极低 | 音频编码 | 低 |
| Opus | 低 | 极低 | 实时通信、VoIP | 极低 |
你看，AV1编码复杂度极高，软件编码基本是CPU杀手。我建议，除非你有专门的硬件加速，否则别在通用CPU上跑AV1软件编码，那是给自己找麻烦。
3.2 进程调度策略：谁先跑，谁后跑
CPU就那么多核，进程却有一大堆。谁先跑，谁后跑，这就是调度策略的事。Linux默认用的是CFS（完全公平调度器），但多媒体流系统，尤其是实时流，需要更精细的控制。
为什么会这样？因为编解码器、网络收发、渲染显示，这些任务对延迟的敏感度不一样。音频解码延迟超过20ms，人就能感觉到卡顿。视频解码延迟超过100ms，交互体验就很差了。
我建议，把关键任务绑定到特定CPU核心上，并设置合适的调度策略和优先级。具体怎么做？
- 使用
taskset绑定CPU核心：把编解码器进程绑定到物理核心，避免它在不同核心间跳来跳去，减少缓存失效。 - 设置实时调度策略：对于音频处理、网络收包等硬实时任务，使用
SCHED_FIFO或SCHED_RR，并设置高优先级。 - 隔离核心：通过内核启动参数
isolcpus，把某些核心完全留给关键任务，不让其他进程干扰。
小技巧：我曾经在一个项目中，把音频解码线程绑定到CPU 0，并设置SCHED_FIFO优先级为99。结果音频卡顿问题直接消失。但要注意，实时优先级太高，可能会把系统其他进程饿死，要谨慎。
这里有个配置示例，你可以参考：
# 将进程PID 1234绑定到CPU 0和1
taskset -cp 0,1 1234
# 设置进程PID 1234的调度策略为SCHED_FIFO，优先级为80
chrt -f -p 80 1234
# 查看当前调度策略和优先级
chrt -p 1234
3.3 上下文切换开销：看不见的CPU小偷
上下文切换，就是CPU从一个进程/线程切换到另一个。每次切换，都要保存当前状态，加载新状态。这本身就要消耗CPU周期。如果切换太频繁，CPU大部分时间都在“换人”，而不是“干活”。
我见过一个案例，系统CPU占用率只有30%，但吞吐量就是上不去。用vmstat一看，cs（context switch）列的数字高得吓人，每秒几十万次。这就是典型的“上下文切换风暴”。
为什么会这样？通常是因为线程数太多，或者锁竞争太激烈。每个线程都在抢锁，抢不到就挂起，挂起就触发切换。切换回来又抢不到，又挂起……恶性循环。
怎么排查？我一般用perf stat -e context-switches来统计。如果上下文切换次数超过每秒几万次，就要警惕了。
避坑指南：我曾经在一个项目中，为了追求“高并发”，把线程数设成了CPU核心数的4倍。结果上下文切换开销占了CPU总时间的30%以上。后来把线程数降到核心数的1.5倍，性能反而提升了50%。
减少上下文切换的几个方法：
- 减少线程数：用线程池，复用线程，避免频繁创建和销毁。
- 使用无锁数据结构：比如
lock-free queue，减少锁竞争。 - 批量处理：把多个小任务合并成一个大任务，一次性处理，减少切换次数。
- 使用协程：协程的切换开销远小于线程，适合IO密集型任务。
3.4 中断处理：硬件在敲门
中断，就是硬件告诉CPU“我有事找你”。比如网卡收到一个数据包，就会触发一个中断。CPU收到中断，就得暂停当前工作，去处理中断。处理完了，再回来继续。
中断处理分上半部和下半部。上半部（硬中断）要快，只做最必要的事，比如把数据从硬件拷贝到内存。下半部（软中断）可以慢一点，做更复杂的处理，比如协议解析。
在多媒体流系统中，网络中断和显示中断是最常见的。如果中断频率太高，CPU会被频繁打断，导致编解码器无法连续运行。
我建议，使用中断合并（Interrupt Coalescing）和NAPI（New API）来减少中断次数。中断合并，就是把多个中断合并成一个，批量处理。NAPI是Linux网络子系统的机制，在高速网络下，用轮询代替中断，减少中断开销。
注意：中断合并虽然能降低CPU占用率，但会增加延迟。对于实时性要求高的场景（比如音频），要谨慎使用。我一般会针对不同网卡队列，设置不同的合并参数。
查看中断分布，可以用cat /proc/interrupts。你会看到每个中断号在每个CPU核心上的触发次数。如果某个核心的中断特别多，可以考虑用irqbalance或者手动设置smp_affinity，把中断分散到不同核心上。
# 查看中断分布
cat /proc/interrupts
# 手动设置中断亲和性（以网卡中断为例）
# 假设网卡中断号为 48，将其绑定到 CPU 2 和 3
echo "0c" > /proc/irq/48/smp_affinity
3.5 知识体系总览
好了，上面讲了四个核心点。我画了一张图，帮你把整个知识体系串起来。
这张图把四个维度串起来了。你看，编解码器是CPU消耗大户，调度策略决定了任务怎么排队，上下文切换是隐藏的CPU小偷，中断处理是硬件在敲门。四个维度互相影响，一个地方出问题，整个系统都可能崩。
嗯，这一章的内容就到这。记住，分析CPU瓶颈，不要只看CPU占用率这一个指标。要结合上下文切换、中断分布、调度策略一起看，才能找到真正的根因。