《泛娱乐行业技术服务白皮书》——三、泛娱乐典型业务架构与场景——3.2 游戏类泛娱乐——3.2.2 游戏泛娱乐技术服务(11)

简介: 《泛娱乐行业技术服务白皮书》——三、泛娱乐典型业务架构与场景——3.2 游戏类泛娱乐——3.2.2 游戏泛娱乐技术服务(11)

《泛娱乐行业技术服务白皮书》——三、泛娱乐典型业务架构与场景——3.2   游戏类泛娱乐——3.2.2 游戏泛娱乐技术服务(10) https://developer.aliyun.com/article/1230983?groupCode=supportservice



3.2.2.3.6 解决之道


现在我们经过多轮的验证与排查、观察,可以发现FBC,降低TDR是完成单台 VM<100次黑屏的解决之道,但是解决仅仅是切换DDA即可吗?答案显然不是,虽然 黑屏情况有了大幅提升,但是离客户的核心诉求依旧有一定差距(平均200+,目标 <100),另外DDA是否有其他坑?答案是肯定的,切换DDA后,虽然黑屏减少了很 多,但是编码采集慢问题有了线性增长,可以说为了解决黑屏问题却引入了次生问 题,同时DDA接口是一个高度集成的接口,即Rendering+Encode是合在一起的,对 于定位是具体什么链路导致的采集慢无法定位(后经过NV确认,DDA在微软侧已经确 认了存在非预期采集慢问题,但是由于底层机密无法透露具体原因,只承诺在新版本 会找解决方案,这就是一开始为什么提依赖于厂商链路的原因,依赖厂商相对可控性 就低了,比较黑盒),所以解决方法只能往FBC上想,脑暴汇聚如下:


image.png


 答案比较明显,在现有驱动版本的情况明确了在GRID12(图中A)下对于NVFBC、 DDA均不支持,作为售后角色综合考虑客户侧业务情况(友商驱动在GRID9下运行正 常)与业务线情况(友商步步紧逼,成本压力大),在当下上量节点,方案就仅剩余通过 降级驱动来评估是否FBC情况能否有明显改善,权衡后与研发一同讨论,确认启动 GRID11+NVFBC方案评估,这样即可以为NV去分析GRID12下FBC、DDA的异常问题 争取时间,同时也不影响客户上量诉求,另外GRID11本身也比其他友商要高两个级 别,在功能特性上有加分,若通过的话,该问题算是里程碑突破,当下立断,评估客 户侧环境,确认采用20/80测试,将20%机器采用带有降级驱动的镜像进行重新部 署,观察效果,经过两周观察再逐步拓展到全量,总体看优化前后平均黑屏数 393.93次下降到目前51.15次,优化了87.01%,大部分在个位数,基本达到优化效果。


总结:

•系统内:

o游戏进程,最好有游戏发行线测试,在确认上架前的POC阶段加入游戏对于负 载,特别是GPU负载的压力如何。


o驱动版本,老生常谈,合适的驱动版本 > 匹配的驱动版本 > 新版本驱动,特别 是NV厂商,坑坑洼洼很多,很多问题换个前端驱动(所谓的后端驱动就是宿主机层面层面的虚拟化驱动)可能就解决了


o游戏核心链路协议:DDA在某些特定游戏场景下有坑,采集慢,同时链路耦合 度太高,不便于排查,但是对于新Guest1OS版本友好(虽然在GRID112上有坑), FBC是NV老牌接口,目前已确认废弃(对特定客户开放持续支持,比如本篇中的客户 就是NV单向承诺了,所以才敢继续使用),但是其相关链路分开,不同链路间可打点 位置多,对于游戏业务比较友好。


o设备层面:从设备管理器看可以确认映射的虚拟显卡是否有被注册到OS内的 PCI接口上,若有显示但是未能被正确识别则很可能是驱动问题;


•系统外:

oGPU硬件(更建议找虚拟化团队、AIS团队):从从业经历来讲,GPU硬件应该是 为数不多能够与内存故障相匹敌(如果相同基数的情况)的部件了,在本次专项中笔者 做得最多的就是上NC、VM打nvidia-smi(VM内部看到得更多是进程对应的GPU损 耗),  这个可以确认GPU是否存在掉卡以及显性的UCE错误,  而对于GPU硬件故障也 可以看对应NC或CN的具体message,看看是否有XID之类(有XID不一定是硬件故 障,具体可参阅NV的XID列表)的报错:


image.png


o软件层面(更建议找虚拟化团队、管控团队):可以重点检查下vmem分配情况以及相 关xml对应的pci设备是否正常,还有后端版本是否符合预期。

 

3.2.2.4 游戏陪练场景与架构


3.2.2.4.1 游戏陪练简介


游戏陪练是指陪客户玩指定的网络游戏,并提供随程语音、文字聊天服务。


陪练服务也分为有偿和无偿两种。有偿陪练是指玩家个人主动提出需求,并需要 支付一定的报酬才能够获得陪练服务;无偿陪练通常是游戏厂商为推广游戏而安排人 员在网吧陪伴玩家。当然,也有一些游戏公司让员工在游戏里陪玩家玩,借机圈钱。 其中,  有偿陪练是一种被游戏玩家逐渐关注的全新游戏服务形式。之前报道的魔兽 VIP会所便是专门为有钱人提供的线下陪练服务,但这样高规格游戏陪玩服务属于凤 毛麟角,网上讨论比较多的还是线上游戏陪练。有偿游戏陪练分为两种:


1)第一种是游戏陪练江湖中的自由派,个人单个和用户陪练,不愿意加入任何 游戏组织公会,他们的生意有时候会很冷淡,需要自己在各个社交平台上推销自己。


2)第二种是加入一定游戏组织公会,价格收取就高很多,有时候游戏公会组织 会给派一些比较好的陪练单,这样的陪练费会更高。对于游戏陪练服务,有评论称这 可以满足部分玩家追求热闹的游戏需求。但也要谨防陪练过程中产生的利益纠纷或诈 骗行为,以及警惕借游戏陪练之名进行色情活动等违法情况的出现。



《泛娱乐行业技术服务白皮书》——三、泛娱乐典型业务架构与场景——3.2   游戏类泛娱乐——3.2.2 游戏泛娱乐技术服务(12) https://developer.aliyun.com/article/1230979?groupCode=supportservice

相关实践学习
在云上部署ChatGLM2-6B大模型(GPU版)
ChatGLM2-6B是由智谱AI及清华KEG实验室于2023年6月发布的中英双语对话开源大模型。通过本实验,可以学习如何配置AIGC开发环境,如何部署ChatGLM2-6B大模型。
相关文章
|
11月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
1161 0
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
369 17
|
运维 监控 负载均衡
探索微服务架构下的服务治理:动态服务管理平台深度解析
探索微服务架构下的服务治理:动态服务管理平台深度解析
|
运维 监控 安全
探索微服务架构下的服务治理:动态服务管理平台的力量
探索微服务架构下的服务治理:动态服务管理平台的力量
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
|
11月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
445 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
569 14
文生图架构设计原来如此简单之分布式服务
|
存储 人工智能 自然语言处理
Cursor这类编程Agent软件的模型架构与工作流程
编程Agent的核心是一个强大的大语言模型,负责理解用户意图并生成相应的代码和解决方案。这些模型通过海量文本和代码数据的训练,掌握了广泛的编程知识和语言理解能力。
1337 1
|
消息中间件 存储 大数据
阿里云消息队列 Kafka 架构及典型应用场景
阿里云消息队列 Kafka 是一款基于 Apache Kafka 的分布式消息中间件,支持消息发布与订阅模型,满足微服务解耦、大数据处理及实时流数据分析需求。其通过存算分离架构优化成本与性能,提供基础版、标准版和专业版三种 Serverless 版本,分别适用于不同业务场景,最高 SLA 达 99.99%。阿里云 Kafka 还具备弹性扩容、多可用区部署、冷热数据缓存隔离等特性,并支持与 Flink、MaxCompute 等生态工具无缝集成,广泛应用于用户行为分析、数据入库等场景,显著提升数据处理效率与实时性。
|
存储 JavaScript 开发工具
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
本次的.HarmonyOS Next ,ArkTS语言,HarmonyOS的元服务和DevEco Studio 开发工具,为开发者提供了构建现代化、轻量化、高性能应用的便捷方式。这些技术和工具将帮助开发者更好地适应未来的智能设备和服务提供方式。
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】