直播服务器CPU占用过高怎么办，有哪些优化方法？

直播服务器CPU占用过高，最直接的解决办法是分层排查：先看直播软件和推流编码是否吃满单核，再查系统进程和恶意占用，最后根据并发规模决定升级CPU还是改用硬件编码分流。

直播这件事，最怕的不是网络抖动，而是服务器CPU突然飙到90%以上，画面开始卡顿、掉帧，观众弹幕刷“卡了”，作为常年跟直播服务器打交道的人，我见过太多因为CPU爆满导致的翻车现场，今天就把排查思路和解决路径一次说清楚,全是可落地的操作。

加载中

服务器常见问题之cpu占用率过高

不

不思进取的小k

3466--

原视频地址

直播服务器CPU占用过高的常见原因排查

CPU不会无缘无故满载，它背后一定有一个或多个进程在疯狂消耗算力，你需要先登录服务器,用命令看清楚到底是谁在吃CPU。

用top命令快速定位CPU占用进程

SSH登录服务器后,直接输入：

top -c

按P键让进程按CPU使用率排序,这时候你会看到两类典型情况：

• 某个ffmpeg或obs相关进程占用极高，说明是推流编码的问题
• 进程列表里出现陌生名字，比如xmrig、kdevtmpfsi，说明服务器可能被挖矿病毒入侵了

如果进程名不明确，用ps -ef查看完整路径，或者lsof -p PID看这个进程打开了哪些文件。

区分直播软件占CPU还是系统进程占CPU

直播场景里,CPU被吃掉主要来自三个环节：

1. 视频编码：把摄像头或游戏画面压缩成H.264/H.265流，这个操作极其耗CPU
2. 转码分发：服务器把一路直播流转成多路不同码率给不同观众，每多一路转码就多一份CPU开销
3. 网络协议处理：大量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杀手

很多团队会自己搭建直播服务器，用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端口,攻击面很大。

应急处置流程

按顺序执行,不要跳过：

1. 立即在云控制台创建服务器快照，保留证据
2. 用kill -9 PID杀掉挖矿进程，但做好它复活的准备
3. 检查crontab -l，清理定时任务里的恶意下载脚本
4. 检查/root/.ssh/authorized_keys，删除陌生公钥
5. 修改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主频普遍更高。