mediasoup room在达到一定并发观众量时,就会发生画面不清晰,卡顿严重的情况。

故障发生时,观察到推流器obs的码率发生了严重下降,由正常的1.5Mbps下降到约400kbps,显然,这个encoding码率就会导致严重的画质问题。画面不清晰是由于过压(bitrate不足)导致的,而lag严重是由于FPS过低导致。

可能的原因:

  1. Obs与服务端origin-node协商,降低了bitrate和fps。服务端是mediasoup-worker,应该是它检测到网络质量差的情况下,和encoding端协商降低quality level。
  2. Obs推流过程发生严重的udp丢包行为。丢包有三种可能:Origin-node太忙,质量控制算法原因主动丢包,网络差。

几个room在同样的推流端网络条件下,应该不是网络差的原因。而origin-node cpu load不高,也就不是太忙的原因。唯一的可能性就是主动调降了quality level,进行了主动的丢包操作。为什么会主动调整quality level呢?可能的原因如下:

  1. 一个worker承担的room超过了合理值。根据实测,一个cpu core能够支持400个并发,超过这个值后bitrate会快速下降,由此导致画质下降。

Action: 统计出ms-worker的数量,每个ms-worker上承载的room数量。

  1. Ms-worker不是最新的code,一些bug解决了没有merge进来。

Action: 编译生成mediasoup-worker,更新到wrs-node项目。

  1. Origin-node和edge-node没有切分开,由此导致wrs-obs被降级。

Action: 在edge-node做re-encoder,把两种类型节点完全切分开。

  1. 不管什么机制触发了质量调节,不丢包。

Action: 推流侧改为RTCP/TCP传输,不用UDP。

由于我们并没有采用simulcast/svc分层质量等级机制,质量的下降应该是被动行为。换句话说,就是udp丢包比较严重,这首先应该发生在viewer side。在发生了viewer侧的严重丢包事件后,viewer-node会请求origin-node重传。这个重传机制带来的严重后果就是影响到推流端的传输功能,有效传输的bitrate下降,画质严重下降。

viewer侧的严重丢包,通过”重传请求”传递到了origin-node side,进而影响到推流端视频流传输,encoding stream quality发生严重下降。经过调查发现,async createPipeTransport({ listenIp, port, enableSctp = false, numSctpStreams = { OS: 1024, MIS: 1024 }, maxSctpMessageSize = 268435456, sctpSendBufferSize = 268435456, enableRtx = false, enableSrtp = false, appData = {} })

enableRtx = false,此重传功能就没有打开。

需要继续定位问题:Router的工作量分配不均等导致?

首先,升级mediasoup 至3.10.8. 为保证效果,mediasoup-worker需要合理分配,分离出一个单独的ms-worker作为pipe-worker来使用,而其它的ms-worker组成pool给user使用。多cpu框架下,一个cpu上启动一个ms-worker进程,这是由OS自动管理的。

重新编译最新的mediasoup-worker过程记录

$ Git clone GitHub - versatica/mediasoup: Cutting Edge WebRTC Video Conferencing

$ npm run typescript:build  //得到node/lib

$ cd worker&&make                 //得到out/Release/mediasoup-worker

把编译输出的结果手工copy到nodejs工程的node_moduels/mediasoup/下面即可,这是手工更新。

mediasoup性能瓶颈分析相关推荐

  1. 动态执行流程分析和性能瓶颈分析的利器——gperftools的Cpu Profiler

    在<动态执行流程分析和性能瓶颈分析的利器--valgrind的callgrind>中,我们领略了valgrind对流程和性能瓶颈分析的强大能力.本文将介绍拥有相似能力的gperftools ...

  2. 动态执行流程分析和性能瓶颈分析的利器——valgrind的callgrind

    在<内存.性能问题分析的利器--valgrind>一文中我们简单介绍了下valgrind工具集,本文将使用callgrind工具进行动态执行流程分析和性能瓶颈分析.(转载请指明出于brea ...

  3. linux服务器宕机分析/性能瓶颈分析

    linux服务器宕机分析/性能瓶颈分析 服务器宕机原因很多,资源不足.应用.硬件.系统内核bug等,以下一个小例子 服务器宕机了,首先得知道服务器宕机的时间点,然后分析日志查找原因 1.last re ...

  4. 通过 Java 线程堆栈进行性能瓶颈分析

    改善性能意味着用更少的资源做更多的事情.为了利用并发来提高系统性能,我们需要更有效的利用现有的处理器资源,这意味着我们期望使 CPU 尽可能出于忙碌状态(当然,并不是让 CPU 周期出于应付无用计算, ...

  5. java 性能瓶颈_如何通过 Java 线程堆栈来进行性能瓶颈分析?

    改善性能意味着用更少的资源做更多的事情.为了利用并发来提高系统性能,我们需要更有效的利用现有的处理器资源,这意味着我们期望使 CPU 尽可能出于忙碌状态(当然,并不是让 CPU 周期出于应付无用计算, ...

  6. 性能测试培训:性能瓶颈分析思路

    性能测试培训:性能瓶颈分析思路 poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标.在poptest的loadrunner的培训中,为 ...

  7. mysql性能瓶颈分析和内存占用高的优化

    微信公众号:我其实目前没有耶 我是一个互联网公司的螺丝钉; 魔术师耿 mysql服务器性能瓶颈分析和内存优化 前言 开发阶段,对项目中mysql使用在代码层面已经做了最大努力的优化: 大表减少关联查询 ...

  8. 流媒体学习之路(mediasoup)——拥塞控制分析(6)

    流媒体学习之路(mediasoup)--拥塞控制分析(6) 文章目录 流媒体学习之路(mediasoup)--拥塞控制分析(6) 一.TransportCongestionControlClient ...

  9. mysql的性能瓶颈分析、性能指标、性能指标信息的搜集工具与方法、分析调优工具的使用...

    性能瓶颈: 慢.写速度比读速度慢很多  主要的性能指标: 访问频度, 并发连接量, 缓存命中率, index使用, slow log开启与分析, query Log,查询log Threads_cac ...

最新文章

  1. java ee webservice_javaEE调用webservice总结【利用WSDL】(转载)
  2. 1. python 字符串简介与常用函数
  3. SQL Server中常用的SQL语句
  4. containerd 与安全沙箱的 Kubernetes 初体验
  5. vue 2.0 无法编译ES6语法
  6. .NET Core 小程序开发零基础系列(2)——小程序服务通知(模板消息)
  7. 在linux下利用ls命令进行模糊查找
  8. 最高效的进(线)程间通信机制--eventfd
  9. CVPR 2019 Oral | 京东目标检测算法ScratchDet的深入思考
  10. 转载-使用Nodepad++来编辑我们服务器的配置文件
  11. Jmeter如何将上一个请求的结果作为下一个请求的参数——使用正则表达式提取器转载...
  12. Android 开源框架Universal-Image-Loader完全解析(二)--- 图片缓存策略详解
  13. java从入门到放弃(一)
  14. 基于SSM的大学生就业信息管理系统
  15. 华为网络设备-访问控制列表配置实验
  16. C++:实现标准体重判定
  17. 关于微信的几点更新与操作
  18. STM32F303RE 四个ADC同步规则采样
  19. ZZULIOJ:1001植树问题
  20. java快速排序的时间复杂度_程序猿必备排序算法及其时间复杂度分析

热门文章

  1. scanf,getchar:拿来吧你!!!
  2. C语言之getopt函数
  3. 易语言调用API之打印函数
  4. 【汽车电子】5分钟了解汽车操作系统(科普篇)
  5. 【NVIDIA】GeForce-GTX-1080Ti单算法服务内存显存占用
  6. 为什么hashcode的算法要用31作为乘子
  7. Windows打开端口3306
  8. jQuery中的hover事件
  9. jdbc步骤java_jdbc连接数据库的5个步骤
  10. 论文快速降重的一点实用性见解(仅供参考)