炼数成金 门户 大数据 存储 查看内容

广电采集系统IO优化一例

2016-12-28 10:53| 发布者: 炼数成金_小数| 查看: 19660| 评论: 0|原作者: 冬瓜哥|来自: 大话存储

摘要: 广电行业,涵盖由监管、电视台、制作公司、网络电视台等单位组成的产业生态。而广电行业的主要业务,业内有多种叫法,比如媒体云、全台网、融合生产等等,不管叫什么,整个流程都会涉及到采、编、播、管、存这几个步 ...

存储 Hadoop 服务器 硬件 存储系统

之前文章中,冬瓜哥为大家介绍了气象海洋超算领域FVCOM系统(有限体积海岸海洋模型)的IO优化案例,网友反响不错。本次再为大家介绍一例广电采集系统的IO优化案例。必须指出,没有任何存储系统可以在任何场景下都体现出最优的IO性能,需要经过精校,可以说这是软件定义存储“场景化定制”的关键所在。对于久经沙场的产品,出货量越多,遇到过的坑和场景越多,其产品积累的就越稳定、越优异。
 
广电业务 每一步都要和存储打交道

软件定义存储在广电场景的应用
 
广电行业,涵盖由监管、电视台、制作公司、网络电视台等单位组成的产业生态。而广电行业的主要业务,业内有多种叫法,比如媒体云、全台网、融合生产等等,不管叫什么,整个流程都会涉及到采、编、播、管、存这几个步骤。每个步骤都会与存储打交道,这次重点介绍采集系统。

采编播管存等流程和存储密切相关
 
采集系统作为整个广电系统的输入来源,重要性不言而喻。其涉及诸多关键技术,比如数字音频、转码技术、声音和合成与处理等等。存储子系统是否持续输出稳定的数据流,是上述这些技术是否得以发挥的关键。
采集系统简单来说,就是接收卫星传输数据,通过采集服务器,把原始码流和转换后的数据放到存储中,为后续的编、播、管、存提供数据基础。其大致流程如下:

广电行业数据采集业务
 
广电采集的IO特征:稳定带宽和高并发
视频流业务追求的是持续稳定的带宽,以及足够高的并发量,对时延反而不敏感。其对存储系统的要求是链路需要足够稳定,误码率低,这就对HBA控制器的硬件质量和固件、驱动稳定度提出了要求;另外,要求缓存刷盘管理足够稳定,一般来讲刷盘会导致前端IO性能受到影响,常规做法是锁住对应页面,执行从刷盘到解锁再到优化的操作,另外还有一些的做法是采用无锁设计。总之,为了让单路码流稳定持续,在IO路径上增加足够的缓冲是关键,其次为了满足多路并发的需求,后端的并发度也要足够高,从接口到后端硬盘,其数量应该足够高;内部IO处理模块之间也需要有足够的队列数量和足够的深度用来缓冲。

基于文件协议的访问方式是广电领域中最常用的方式,虽然偶尔用块存储,但是更多还是NAS类访问居多。其可以有NFS、CIFS等标准协议,也可以有厂商的私有文件访问协议。但是不管怎样,应用系统看到的必须是一个文件目录,而不是块设备盘符。
 
采集系统IO优化一例
某广电客户采集业务,分了两部分,一部分是音视频节目流(500路节目流,码率1.5Mb/s,客户端每缓存2MB写一次,每一次耗时0.2s),第二部分是原始码流(100路源码码流,码流32Mb/s,客户端每缓存8MB写一次耗时0.6s),共有6台视频采集服务器,每台采集服务器最多配置15个节目,因为所有的节目需要用CPU进行转码,由MPEG2转为H264,很耗费CPU,所以每一台采集服务器支持的节目数量是有限的(目前客户主机现在最多支持15路节目码流)。
该用户原先使用了某品牌传统双控存储系统,但是由于性能无法达到预期目标,并且无法满足业务持续增长所带来的容量和性能扩展要求,后升级到了浪潮AS13000-Rack大规模机架式分布式存储系统,AS13000-Rack不仅支持块存储访问方式,还支持NFS、CIFS以及浪潮私有协议访问,而NAS方式的访问也是广电系统中最常用的访问模式。

浪潮整机柜软件定义存储

节点布局

整机柜SDS性能优化原理

浪潮软件定义存储的两种产品形态

案例过程分析 
在项目POC测试时,6台采集服务器在跑客户应用时出现3台正常,2台有5秒的连接断开,然后迅速恢复连接并进行IO;一台有一分钟的连接断开。这种诡异的现象在其他场景下并没有观测到,这显然与广电采集系统的持续码流+高并发度这种IO特征有很大的关系。这直接关系到存储系统的内核IO处理栈中对这类IO特征的适配,包括缓冲、路径长度、高并发多线程之间的资源同步等复杂问题。

浪潮派出了场景看护SE、软件高级工程师、硬件高级工程师和POC测试代表来现场分析并解决问题。最了解应用场景的场景看护SE对上层应用软件的IO行为用了Strace和BlockTrace工具跟踪以及对系统日志做了详细分析,同时由存储系统软件工程师全面分析存储系统内部的进程状态、日志内容以及全IO路径上各个模块的状态,定位目前问题可能原因有三个方面:

1、一台长时间(1分钟)采集服务器断开,主要是因为smb协议的SMBD进程僵死,导致僵死的原因是SMB多线程池的mutex和异步线程的mutex发生死锁,至于死锁的原因,与采集系统的持续高码流和高并发度有直接关系,这是其他类似场景中碰不到的一个坑。
2、两台短时间(5s)采集服务器断开,主要原因是存储系统的部分文件访问接口调用耗时较长,导致客户端(采集服务器)主动断开连接,客户端(采集服务器)应用在断开连接后写入不进去,在尝试三次之后,会关闭当前文件,重新创建文件,这个时候会重新创建连接进行挂载。经过反复排查,耗时较长的接口分别是:fstat , statfs和stat,通过定位,三个接口耗时总计超过28s,这对时间要求极高的采集业务系统,是不可接受的。
3、通过日志还发现,有些IO请求时延高达60s,而且日志中看kernel报出attempting task abort! scmd(ffff8801734b1180),怀疑是硬件问题导致,比如HBA驱动、硬盘等。

精准校调  逐一解决
有了上述分析方向,工程师加班加点开始解决问题。推荐解决死锁的坑,修改对应代码;其次IO访问关键路径优化,修改Stat、statfs和stat的调用的过程,精简路径以及优化数据结构和访问模式,最终优化到了5s内;硬件排查磁盘、SAS卡、背板等对硬件逐层“解剖”跟踪,SAS分析仪抓包测试,并最终得出结论,SAS卡驱动有缺陷,经过报交厂商解决后升级SAS卡驱动;所有问题解决,发布补丁包并升级用户现场系统。 
 
调优效果
 
最终,客户的6台采集服务器成功上线,500路节目流和100路的原始视频流稳定运行。
 
浪潮存储目前已经全面启动针对业界八大典型行业应用的深度分析和优化。不懂用户业务场景的存储系统不是好系统。存储系统必须可以灵活的针对上层应用场景灵活适配。冬瓜哥不禁又想起了5年前的那个产品设计,能够自适应任何场景的IO优化问题,而且不停机。可惜啊,可惜。冬瓜哥当时问产品线要人,说给我一支队伍我给你弄出来。可惜啊,对牛弹琴啊。不过冬瓜哥欣喜的看到浪潮已经把应用适配上升到了战略高度层面,冬瓜哥认为其他存储系统厂商更应该学习浪潮这种模式,将应用适配进行到底。在此,冬瓜哥也很欣赏浪潮愿意将其自己的经验共享给业界,而不是自己闷着吃独食,显示出了浪潮的业界大厂的风范。

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967

鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2017-11-18 21:52 , Processed in 0.163351 second(s), 25 queries .