一台 8 核机器上同时跑 6 个 ffmpeg，load average 冲到 32，接口响应从 80ms 涨到 2 秒。ps 里每个进程 CPU 都在 300% 以上，x264 默认按核数开线程。日志里能对上时间点，这种反而好排。
libx264 默认 threads 等于逻辑核数，6 个任务各自开 16 线程，互相抢 CPU。转码是计算密集的，线程一多上下文切换反而拖慢每个任务。同机部署的 web 服务跟着被挤。这一点先确认清楚，后面就不用反复试。
ffmpeg -i in.mp4 -c:v libx264 -threads 4 -preset medium -crf 23 out.mp4 nice -n 15 ffmpeg -i in.mp4 -c:v libx264 -threads 2 out.mp4
「FFmpeg CPU 占用」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：给 ffmpeg 显式加 -threads 限制 单任务不超过 4；用 nice 或 cgroup 把转码进程降到低优先级；把转码和 web 服务分机器 至少分不同 cgroup；观察 load 和单任务耗时 找吞吐和延迟的平衡点。
结果对不对很好判断，load average 稳定在 8 以下，接口 P99 回到 200ms 以内，单任务转码耗时只多了 15%。