从一次线上卡顿排查讲起:手把手教你用SRS内置工具和系统命令定位流媒体性能瓶颈
从一次线上卡顿排查讲起手把手教你用SRS内置工具和系统命令定位流媒体性能瓶颈深夜11点运维工程师小李的手机突然响起告警——直播业务核心指标出现异常波动。监控大屏显示多个CDN边缘节点的卡顿率在10分钟内从0.3%飙升到8.7%。作为SRS流媒体服务的负责人他需要快速定位这个突如其来的性能瓶颈。本文将还原这次故障排查的全过程展示如何结合Linux系统工具和SRS内置能力进行深度诊断。1. 建立性能基准从监控指标到问题表征任何有效的性能排查都始于对异常现象的准确定义。我们首先需要确认几个关键问题卡顿的时间特征是持续出现还是间歇性波动本例中卡顿率曲线呈现锯齿状上升暗示可能存在资源争用影响范围所有流都受影响还是特定编码格式/协议通过SRS的/api/v1/vhosts接口发现HLS流正常而RTMP流异常资源水位top命令显示CPU空闲率保持在70%以上排除计算资源瓶颈提示在SRS配置中开启pithy_print_ms 1000可获取秒级精度的日志输出这对捕捉瞬时异常至关重要通过初步排查我们将问题范围缩小到RTMP协议的传输环节。接下来需要系统性地检查网络栈和SRS内部状态。2. 网络传输层深度诊断2.1 连接状态分析使用ss -tunp命令查看活跃连接状态重点关注ss -tunp | grep srs tcp ESTAB 0 0 192.168.1.10:1935 203.156.34.12:48234 users:((srs,pid1123,fd18)) tcp ESTAB 1120 0 192.168.1.10:1935 203.156.34.15:48236 users:((srs,pid1123,fd19))异常现象存在大量ESTABLISHED状态但长时间无数据传输的连接接收队列(Recv-Q)积压数据超过正常值通常应小于10KB2.2 带宽与包分析通过iftop -i eth0 -P观察实时流量发现出向流量存在明显的周期性突刺单个连接的平均吞吐量(1.2Mbps)低于预期配置(3Mbps)结合tcpdump抓包分析发现TCP窗口缩放频繁触发提示可能存在缓冲区设置不当tcpdump -i eth0 -nn port 1935 -c 100 -w rtmp.pcap3. SRS内部状态剖析3.1 实时API监控SRS的HTTP API提供了丰富的内部状态数据。关键端点包括API路径作用关键指标/api/v1/summaries服务器全局状态nconn当前连接数/api/v1/streams活跃流信息frame_rate各流帧率/api/v1/clients客户端详情kbps各客户端实际带宽通过curl http://127.0.0.1:1985/api/v1/summaries获取的数据显示{ code: 0, server: 1123, connections: 842, rx_bytes: 125893212, tx_bytes: 98321233 }当前连接数(842)已接近配置的max_connections1000阈值。3.2 日志关键线索调整日志级别后在/var/log/srs.log中发现大量重复警告[WARN] [1123] [0] [RTMP drop packet] size1420, queue120ms这表明合并写入(MW)缓冲区已饱和开始丢弃数据包。4. 配置优化与验证4.1 关键参数调整根据排查结果对conf/srs.conf进行针对性优化vhost __defaultVhost__ { tcp_nodelay on; play { mw_latency 200; # 从350ms下调 chunk_size 65536; # 使用最大块大小 queue_length 10; # 减少客户端缓冲 } } system { max_connections 1500; # 提升连接上限 pithy_print_ms 5000; # 降低日志频率 }4.2 验证方法实施变更后通过以下方式验证效果压力测试srs-bench -c 1000 -r rtmp://localhost/live/stream实时监控watch -n 1 curl -s http://localhost:1985/api/v1/summaries | jq .connections质量评估 使用ffmpeg分析播放流畅度ffmpeg -i rtmp://localhost/live/stream -vf fps30 -f null - 21 | grep frame5. 长效治理机制建立预防性监控体系关键指标告警对nconn、mw_latency等设置阈值告警性能基线记录不同负载下的正常参数范围定期压测每月执行全链路压力测试配置优化不是一劳永逸的工作。随着业务规模变化和SRS版本升级需要持续跟踪/api/v1暴露的指标数据动态调整参数组合。某次版本升级后我们将chunk_size从默认值调整到65536使单机承载能力提升了15%这正体现了持续调优的价值。