3. 推流端硬件排查：CPU、内存与GPU编码负载
推流卡顿，很多时候不是网络背锅，而是你本地的硬件先扛不住了。我见过太多团队，花大把时间调编码参数、换CDN，最后发现是CPU一直在100%跑，或者内存被其他进程吃光了。
这一章，咱们就聚焦在硬件层面。说白了，就是看看你的电脑有没有“带得动”当前的推流任务。
3.1 CPU占用率检查：别让编码器“饿死”
CPU是推流的大脑。x264编码器尤其吃CPU，如果你用的是软件编码，CPU一旦满载，编码线程就会被调度延迟，直接导致帧生成不及时，推流端就开始掉帧、卡顿。
3.1.1 怎么看CPU是否过载？
我个人习惯，在推流的同时，打开任务管理器（Windows）或htop（Linux），盯住这几个指标：
- 整体CPU使用率：如果持续超过90%，基本可以判定是瓶颈。
- 推流进程的CPU占用：OBS或ffmpeg进程吃了多少？如果单进程就占了80%以上，说明编码预设太高了。
- CPU频率是否降频：笔记本用户尤其要注意。温度一高，CPU自动降频，性能断崖式下跌。
3.1.2 避坑指南：别被“总占用率”骗了
你可能会看到CPU总占用只有60%，但推流还是卡。为什么？因为编码是并行任务，如果某个核心被其他进程占满了，编码线程就只能排队。我建议你观察每个核心的负载，而不是只看总和。
3.2 内存使用情况：别让系统开始“交换”
内存不够，系统就会用硬盘当内存——也就是交换（swap）。一旦开始swap，推流进程的响应时间会从毫秒级变成秒级，卡顿是必然的。
3.2.1 关键指标
| 指标 | 正常范围 | 危险信号 |
|---|---|---|
| 物理内存使用率 | < 80% | > 90% 且持续上升 |
| Swap使用量 | 0 MB | > 0 MB 且持续增长 |
| 推流进程内存占用 | 稳定，不持续增长 | 持续增长（内存泄漏） |
我曾经遇到一个案例：推流跑了2小时后开始卡顿，重启后又好了。查了半天，发现是OBS的一个插件有内存泄漏，每帧泄漏几十KB，2小时后吃掉了8GB内存，系统被迫开始swap。换掉插件后，问题解决。
# 查看内存和swap使用情况
free -h
# 查看推流进程的内存占用（假设PID是1234）
cat /proc/1234/status | grep VmRSS3.3 GPU编码负载分析：硬件编码的“隐形坑”
现在很多推流都用GPU硬件编码（NVENC、AMF、QSV），确实省CPU。但GPU编码也有自己的脾气，不是开了硬件编码就万事大吉。
3.3.1 GPU编码的核心指标
你需要在GPU监控工具里看这几个东西：
- Video Encode 引擎占用率：NVENC专用单元的使用率。如果接近100%，说明编码器满载了，再提高码率或分辨率就会丢帧。
- GPU 核心频率与温度：和CPU一样，温度过高会降频，导致编码性能下降。
- 显存占用：虽然编码不占太多显存，但如果游戏或渲染程序已经把显存吃满了，编码器可能会因为显存带宽争抢而变慢。
3.3.2 一个常见的误解
很多人觉得“我用NVENC编码，CPU占用很低，所以没问题”。其实不一定。NVENC虽然不占CPU，但它会占用PCIe带宽和显存控制器。如果你同时在玩游戏，游戏也在疯狂读写显存，两者就会打架。我见过一个案例，用RTX 4090推4K HDR，游戏帧率正常，但推流画面每隔几秒就卡一下。后来发现是显存带宽被游戏占满了，NVENC拿不到足够的带宽去处理编码帧。
3.4 硬件排查流程图：从现象到根因
下面这张图，是我自己排查硬件问题时常用的思路。你可以照着这个顺序走一遍，基本能定位到问题出在哪个环节。
3.5 总结一下排查要点
硬件排查，说白了就是三板斧：
- 看CPU：是不是满载了？是不是降频了？编码线程有没有被饿死？
- 看内存：物理内存够不够？有没有发生swap？推流进程有没有内存泄漏？
- 看GPU：编码引擎占用率多少？显存带宽有没有被其他程序抢走？
这三步走完，90%的硬件相关卡顿都能找到原因。剩下的10%，可能是驱动问题、固件bug或者硬件本身有缺陷——那些就是更深入的排查了。