直播服务器CPU占用过高，最直接的解决办法是分层排查：先看直播软件和推流编码是否吃满单核，再查系统进程和恶意占用，最后根据并发规模决定升级CPU还是改用硬件编码分流。
直播这件事，最怕的不是网络抖动，而是服务器CPU突然飙到90%以上，画面开始卡顿、掉帧，观众弹幕刷“卡了”，作为常年跟直播服务器打交道的人，我见过太多因为CPU爆满导致的翻车现场，今天就把排查思路和解决路径一次说清楚,全是可落地的操作。
直播服务器CPU占用过高的常见原因排查
CPU不会无缘无故满载，它背后一定有一个或多个进程在疯狂消耗算力，你需要先登录服务器,用命令看清楚到底是谁在吃CPU。
用top命令快速定位CPU占用进程
SSH登录服务器后,直接输入：
top -c
按P键让进程按CPU使用率排序,这时候你会看到两类典型情况：
- 某个
ffmpeg或obs相关进程占用极高，说明是推流编码的问题 - 进程列表里出现陌生名字，比如
xmrig、kdevtmpfsi，说明服务器可能被挖矿病毒入侵了
如果进程名不明确，用ps -ef查看完整路径，或者lsof -p PID看这个进程打开了哪些文件。
区分直播软件占CPU还是系统进程占CPU
直播场景里,CPU被吃掉主要来自三个环节：
- 视频编码：把摄像头或游戏画面压缩成H.264/H.265流，这个操作极其耗CPU
- 转码分发：服务器把一路直播流转成多路不同码率给不同观众，每多一路转码就多一份CPU开销
- 网络协议处理：大量TCP/UDP连接、SSL加解密、防火墙规则匹配
如果是第三种，那么CPU占用高往往伴随着网络连接数暴涨，用netstat -an | grep ESTABLISHED | wc -l统计连接数，如果超过几千甚至上万,说明是并发连接把CPU拖垮了。
直播推流电脑CPU占用高怎么解决
很多人的直播服务器其实是一台高性能PC，装的是Windows或者Ubuntu桌面版，这种情况下CPU占用高，通常不是因为服务器端压力,而是推流端编码设置不合理。
优先切换硬件编码器
现代CPU都内置了核显，或者你有独立显卡,完全可以让GPU来干编码的活。
- OBS Studio中，打开“设置 → 输出”，编码器从
x264切换到NVENC（N卡）或AMF（A卡） - 如果是FFmpeg推流，把
libx264换成h264_nvenc,命令示例：
ffmpeg -i input.mp4 -c:v h264_nvenc -preset p4 -b:v 6000k -f flv rtmp://your-server/live/stream
切换后CPU占用率通常能下降70%以上，画面质量损失微乎其微，这个操作对单机直播、甚至是多机位直播都效果显著。
降低编码预设和分辨率
如果必须使用CPU编码（比如服务器没有独立显卡）,那就调整编码预设：
- x264预设从
veryfast改成faster或fast，CPU占用可降低20%-30% - 输出分辨率从1080p降到720p，码率从6000k降到3500k
- 关闭不必要的滤镜、特效、动态元素
有次帮朋友处理一个直播服务器cpu占用过高的问题，他开着1080p60帧的超高码率，还叠加了五个浏览器源，CPU直接满载，后来把画质降到720p30帧，帧率损失小,但直播流畅多了。
直播服务器端转码和并发优化的阶梯策略
如果推流端已经优化到位，服务器CPU还是高,那问题就出在服务器端处理能力上。
限制转码路数，开启按需转码
直播平台常用的策略是：观众默认看原始流，只有网络差的人才能看到低码率转码流,这样服务器不需要为每个观众都转码。
- 在SRS、ZLMediaKit、Nginx-RTMP等流媒体服务器中，配置转码任务的最大并发数
- 设置转码触发条件，比如只有当观众测速低于某个阈值时才生成低码率流
- 使用GOP缓存，让多个观众复用同一份转码结果，而不是每个观众单独转一次
行业共识认为，一个2路转码任务大约需要2个完整CPU核心，如果你只有4核CPU，却开了8路转码,不卡才怪。
直播服务器租用价格与配置选择
很多人不确定直播服务器该租什么配置,我直接给一个参考区间：
| 场景 | CPU核心数 | 内存 | 带宽 | 参考价格区间（月付） |
|---|---|---|---|---|
| 单路推流测试 | 2核 | 4GB | 5Mbps | 50-150元 |
| 中小型直播间 | 4核 | 8GB | 10Mbps | 200-500元 |
| 多人连麦/多路转码 | 8核 | 16GB | 20Mbps | 600-1200元 |
| 高并发直播平台 | 16核以上 | 32GB以上 | 50Mbps以上 | 1500元以上 |
注意，直播服务器租用价格因地区差异很大，国内主流云厂商的竞价实例和轻量服务器价格低，但突发性能受限；香港、日本节点价格略高，但免备案，如果你在做跨境电商直播,香港节点的价格和网络质量值得优先考虑。
直播专用服务器搭建方案中的CPU杀手
很多团队会自己搭建直播服务器，用SRS或者Nginx-RTMP模块，配置不当的话,CPU会在毫无征兆的情况下被吃满。
检查RTMP模块的并发连接数
Nginx-RTMP默认配置没有限制连接数，一旦观众数量激增，每个连接都会占用内存和CPU资源，在nginx.conf中添加：
rtmp {
server {
listen 1935;
application live {
live on;
max_connections 500;
}
}
}
超出的连接直接拒绝,保证已有直播流的稳定性。
禁用不必要的access_log和debug日志
日志写盘也消耗CPU，尤其是高并发下，磁盘IO和CPU都会被拖累，在http或rtmp段中，将日志级别改为error,并关闭access_log：
access_log off; error_log logs/error.log error;
使用CDN或边缘节点分担CPU压力
服务器CPU占用过高还有一个容易忽略的原因：所有观众都直连你的推流服务器，正规直播平台的做法是，推流服务器只负责收流和转码，然后把流推送到CDN边缘节点，观众从最近的点拉流，这样服务器CPU只承担一份推流和一份转码压力,而不是几千份拉流压力。
直播服务器被入侵挖矿导致的CPU异常飙升
如果你发现CPU占用长期接近100%，而且top命令里显示出xmrig、kdevtmpfsi、kinsing之类的进程名，那基本可以判定服务器被入侵挖矿了，这种情况在直播服务器中不少见，因为直播服务需要开放RTMP端口和Web端口,攻击面很大。
应急处置流程
按顺序执行,不要跳过：
- 立即在云控制台创建服务器快照，保留证据
- 用
kill -9 PID杀掉挖矿进程，但做好它复活的准备 - 检查
crontab -l，清理定时任务里的恶意下载脚本 - 检查
/root/.ssh/authorized_keys，删除陌生公钥 - 修改root密码和SSH端口，关闭密码登录改成密钥登录
预防入侵的关键操作
- RTMP端口（1935）不要对全互联网开放，在安全组里只允许推流服务器IP访问
- Web管理面板（比如2000、8080端口）用防火墙限制IP白名单
- 定期用
apt update && apt upgrade -y打安全补丁 - 换用非root用户运行直播服务，降低权限提升风险
据部分云安全厂商公开的统计，直播服务器遭遇挖矿入侵的比例在近两年有明显上升，多数漏洞来自未授权的Redis、Docker和弱口令SSH。
直播服务器CPU占用过高后的性能调优实战
如果你按上面的步骤排查后，确认直播软件正常、没有被入侵、编码也切换到了硬件加速，但CPU仍然偏高,那需要做的是更细粒度的调优。
调整Linux内核网络参数
直播属于高并发网络密集场景，默认内核参数是按通用服务器配置的,优化以下参数能有效降低CPU在软中断上的开销：
# 提高文件描述符限制 ulimit -n 1048576 # 开启TCP快速回收和复用（注意仅适用于NAT模式下） tcp_tw_reuse = 1 tcp_fin_timeout = 30 # 增大接收缓冲区 rmem_default = 65536 rmem_max = 16777216
单核瓶颈的应对措施
直播推流编码是高CPU密集型任务，有时CPU总使用率不高，但某个核心已经跑满，导致视频掉帧，用mpstat -P ALL 1检查单核使用率，如果发现某个核心100%，其他核心闲得发呆,说明进程没有充分利用多核。
解决办法：
- 使用
taskset命令把不同直播流绑定到不同CPU核心上 - 实例代码示例如下：将推流进程绑定到CPU 0-3号核心
taskset -c 0-3 /usr/local/bin/ffmpeg -i rtmp://input -f flv rtmp://output
前段优化后CPU依旧高的最后手段
如果以上都试过，CPU依然在高位运行，那就说明服务器配置确实跟不上直播需求了，这时候不要犹豫，直接升级配置，或者把转码任务迁移到GPU实例上，跟观众卡顿导致的粉丝流失相比,几十块到几百块的服务器硬件成本不值一提。
直播服务器CPU性能瓶颈的监控与预警
等你把CPU占用降下来了，下一步就是搭建监控,防止再次被突然爆满打个措手不及。
安装netdata做实时监控
netdata的安装很简单：
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
安装完成后访问http://服务器IP:19999，你能看到CPU每个核心的使用率、网络流量、TCP连接数等三十多项指标，刷新粒度是秒级，这对于直播场景特别重要，因为直播流量是突发的,分钟级监控看不到峰值。
配置告警阈值
在netdata的健康告警配置中，将CPU使用率告警阈值设为80%持续5分钟，将内存使用率告警阈值设为85%持续3分钟，告警通知接入钉钉或者企业微信机器人，这样即使你在睡觉,服务器出问题也会第一时间收到提醒。
定期进行直播压测
花些时间用模拟工具给直播服务器做一次压测，其实很值得，推荐用ffmpeg -re模拟真实推流，同时用flood工具模拟大量RTMP拉流连接，压测中观察CPU曲线，如果超过80%就是危险信号，超过90%则说明已经碰到了性能天花板。
建议每三个月做一次压测，因为直播功能和观众规模都在变,压测数据能帮你提前发现性能隐患。
直播卡顿怎么解决的Q&A
Q：直播服务器CPU占用高和网络延迟有关系吗？
有关系，网络延迟高会导致TCP重传率上升，网卡中断处理占用CPU的softirq核时间增加，进而表现为CPU占用率升高，你在top命令中看到si数值超过5%，就说明网卡软中断占用了大量CPU，这种情况单纯提升CPU性能没用,需要更换网络质量更好的机房或增加带宽。
Q：使用SRS和Nginx-RTMP哪个更省CPU？
SRS在并发性能上优于Nginx-RTMP，它采用异步IO模型，单进程能管理更多连接，CPU占用也更平稳，Nginx-RTMP更轻量，适合小型直播场景，如果你只有一两路直播流，两者差别不大；如果并发观众超过500人，SRS是更合理的选择,云直播服务的底层大多也是基于这类开源方案二次开发的。
Q：直播服务器的CPU类型对推流帧率影响大吗？
影响很大，直播推流编码属于密集计算任务，CPU的单核性能比核心数量更重要，两颗8核CPU，一颗主频2.0GHz，另一颗主频4.5GHz，推1080p60帧直播时帧率差距可能达到30%，选择云服务器时，优先看CPU主频和CPU型号，比如Intel的Xeon Gold系列和AMD的EPYC系列在单核表现上有明显差距，如果不确定，直接看云厂商提供的“高性能实例”或者“计算型实例”,它们用的CPU主频普遍更高。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774363.html
