Part0 引言
0.1、声明
本篇引用的图片来自于《阿里云2020版PPT素材》以及《暴走漫画制作器(佚名)》，借用部分阿里云产品图标仅做内部标识，如有冒犯，给您跪下（本文核心干货在Part2、Part3，若想节约阅读时间可以直接跳转）。
0.2、vGPU背景
本篇意在记录某互联网华南客户云游戏专项后，技术服务（TAM）侧相关的排障技术与参与了整体专项后的一些收获，希望能够以一个全新的视角给各位看官带来一些vGPU方面的技术体感，在进入正菜之前，我们先看看vGPU（准确来说pGPU也是这个情况）从排障角度到底现在是个怎么样的境地：
【由于本篇会涉及比较多的背景、行业知识，所以看起来会比较“虚头巴脑”，笔者会尽可能挤干水分来讲，同时也会注意不影响到核心部分】
Part1 餐前甜点：技术服务眼中的云游戏
1.1、普通人眼中的云游戏
1.2、普通IT工程师眼中的云游戏
1.3、技术服务(TAM)工程师眼中的云游戏
1.4、技术服务（TAM）看云游戏的衍生
1.4.1、深度领域
云游戏肯定不是单一的通过GPU服务器直接提供给予最终玩家去使用的产品形态（这也是有别于基于VDI实现云桌面的地方），作为技术服务角色需要往深度领域看下，识别出云游戏的关键链路（当然不排除有云游戏业务直接使用类云桌面方式提供给最终玩家使用）。
1.4.2、关键链路
云游戏的技术维度跟视频直播产品有“异曲同工”之妙：
首先，云游戏从具体渲染能力的计算底层（vGPU IaaS VM）捕获画面（这个画面来自于vGPU VM运行真实游戏所产生的），这就类似于直播“推流”，相关平台通过GPU厂商或系统厂商提供的渲染类API进行捕获的动作，相当于视频直播的相关画面往“视频直播中心”推送的过程；
其次，在捕获完成后做的封装动作也与视频直播产品转视频格式再合成（比如M3U8切片TS合成MP4）类似；
最终decode到enduser的最后一屏上，这个最后一屏一般需要由云游戏客户端进行拉取展示，其上的FPS值越高则代表游戏显示层面的顺畅度越高，那与视频直播产品的帧率几乎一致。
1.4.3、关键角色
既然知道关键链路是哪些，就要知道这些链路上部分核心角色（具体图示可见图1）的交互逻辑与定义：
1.4.3.1 渲染计算角色
核心渲染算力提供者，一般为超算（HPC）、GPU（物理GPU能力）、vGPU（虚拟化GPU能力）等机型提供，会出现问题主要捕获阶段、落Log阶段与封装（encode阶段），同时由于与云平台耦合，所以在管控层面（装箱、调度、计算资源分配等）、虚拟化性能分配（CPU算力分配、0进程争抢等）、GPU切分（如有）、前后端驱动（特别是host端驱动）等方面也会经常出现问题，这次某云游戏专项中遇到的核心问题就聚焦在捕获阶段、落Log阶段、前端驱动、虚拟化性能、管控这几个方面，在后面正餐中会具体提到。
1.4.3.2 平台调度角色
核心PaaS能力提供者，一般分为自研与非自研，非自研领域属某手指、海某云为代表的一些平台，本次云游戏专项PaaS平台是由客户与某独立开发商配合一同研制，所以在该角色上我们的沉淀并不多，仅在排障渲染计算角色时了解到该角色主要用在调度相关渲染计算节点并最终提供给玩家使用。
1.4.3.3 最终玩家
如名所示，最终玩家指的是客户ToC部分的末端，在玩家与平台调度角色中还穿插着一些网络角色，比如加速节点调度、专线、图像传输等，最终玩家一般采用PC终端进行游戏业务体验（部分厂商支持移动端）。
这三个角色是本次云游戏专项中体感最强的，同时也是日常排障中涉及最多的角色（特别是渲染计算角色），由于本次专项涉及主要是端游，所以接下来讲的相关排障技术点主要聚焦在端游上，对于手游，阿里云某某游客户会比较深的积累与沉淀，笔者也很期待这次云游戏的客户能够衍生到手游云游戏，这样对于后续移动端云游戏就有更深厚的积累。
Part2 小菜：背景同步
2.1、背景
互联网华南某种重点客户于2019年年中启动云游戏专项，经过多轮验证与多友商PK后确认余下两家云厂商（其中一家为该公司投资方），而阿里云凭借前期的技术攻坚与过硬的IaaS基础底座拿下另外一半，但是在19年至21年7月期间一直问题不断，中间历经多层售后、二线、研发排查分析，最终确认下来核心痛点有：渲染黑屏、RDP卡顿、Log落地慢，而笔者所在的团队就是在这个时间阶段进入，由于该客户约定在10月份将上量（同时也有双十一相关运营活动），若不解决核心痛点将延迟上量，从业务线角度看来将会是一次灾难性的失守，也会在与友商winback过程中处于下风，鉴于此，笔者与众多小伙伴深入客户业务现场，了解到以下背景：
2.1.1、黑屏
渲染黑屏比例在30%+（即测试样例的170台中有50台+存在黑屏情况），Top10黑屏次数台均1k+，最高的一台黑屏次数达到4k+，对于最终玩家来说，偶现的卡顿次数对于实时性要求较低的游戏影响不大，但是大量的黑屏特别是连续黑屏的情况1，对于大部分游戏都是灾难，玩家会明显感知到掉帧、卡顿、回退等，进而退游导致平台PCU下降，来自客户的某次黑屏监控数据（优化前）：
2.1.2、RDP卡顿
客户渲染计算使用的OS版本是Windows Server 2019，在最终玩家进行游戏过程中经常发现后端通过RDP协议连接上去后存在卡顿严重，同时多次出现RDP显示黑屏（与渲染黑屏情况不同），RDP的失效会导致大量的运维动作无法顺利执行，特别是在平台前期还未具备白屏化配置能的情况下，很多时候需要实时上机调试，这个也是上量前较频繁的交互动作，若无法保证将严重影响上量节奏，具体现象如下：
2.1.3、Log慢问题：
由于云游戏涉及的链路较长加上Windows Server相对闭源的特性，要实时感知玩家的体验以及相关链路是否存在异常就重度依赖Log的写入，当出现Log写慢的情况就很可能出现“云游戏之眼”失明以及相关依赖于日志的运维、业务调度策略失效，下图为客户提供的相关Log慢日志：
2.1.4、vGPU掉线、声卡掉线等问题：
此类问题的出现对于云游戏来说都是致命的，不过好在这类问题出现在平台方的原因比较单一，相对于前面三个问题比较好排查，所以单独列在了一起。
2.1.5、采集编码慢问题：
此类问题也会一般比较明确，但是排查时会使用到相关GPU厂商的GPULogView工具，所以相对于前面几个问题要更具备GPU本身的排查代表性。
2.2、目标
当笔者团队接到这个“锅”时，就知道一场大战在所难免，所以在正式开战前，我们对存在的问题以及时间轴有一个大概的优先级排序，黑屏 > Log 慢 > RDP （vGPU与声卡掉线是后期反馈的），现在进行到写这个文章时基本可以按上帝视角列出整个RoadMap了：
简而言之，技术目标就是黑屏次数绝对值要下降到两位数（优化前为4k+），卡屏次数、Log慢、vGPU/声卡问题要优化到0，业务目标就是让这些技术问题不成为上量的卡点，助力某云游戏专项顺利完成，实现GAAP增长。
Part3 主菜：技术排障
3.1、黑屏问题
黑屏问题的难度在于造成黑屏的原因太多了，或者说任一类问题造成的表象都可能包含渲染黑屏，要解决黑屏问题首先的理解，黑屏是怎么产生的，屏幕画像的产生来源于底层渲染计算生成的画面通过解码、封装、捕获等方式呈现出来，一旦出现异常，最先怀疑的就是渲染计算的情况，所以对于黑屏：
3.1.1、系统态排查
我们首先确认了当时系统内相关资源的使用率情况，发现都比较高，特别是CPU资源与GPU资源方面，因为GPU的调度是需要利用CPU资源的（比如队列处理等），而游戏本身占用的CPU可能会很高（特别是3A大作），所以当CPU负载较高时会导致GPU调度不了，形成了成像失败，最典型的情况就是CPU负载很高，GPU负载不高，通过渲染类连接（比如调用了GPU的VNC界面）看是黑屏状态，但是通过RDP协议访问却只是卡顿（因为CPU分配不足），这就是第一个系统态异常的怀疑点，下图为GPU满是最终玩家感觉到黑屏时的任务管理器界面：
通过ProcessExplorer可以看到更具体占用GPU的情况：
通过对应进程获取相关堆栈信息，下图为CPU满时导致的黑屏与RDP卡顿(关于RDP卡顿将在RDP卡顿中详讲)问题可以看到前面9 core（客户使用的VM为定制版的9 core）全部被对应游戏进程占了80%左右：
针对这种情况，我们同步客户后，客户针对我们排查出的游戏进程与游戏发行方进行了联系并做了优化同时也收录了相关数据以便在上量后作为参考执行相关VM配置设计。
3.1.2、平台侧排查
关于第二点，前面说过，CPU使用率是云游戏场景中比较重要的指标，若有其他非主观因素影响了CPU的使用也会导致黑屏几率上升，通过分析宿主机记录的Cacheline相关计数情况，我们发现该客户云游戏VM的Cacheline(当执行原子操作地址未对齐时就会跨越两个Cacheline进行传输，在Intel架构中将这种现象的量级定义为Cacheline引起的问题，而原子地址没对齐的场景，在Intel架构下是允许的，在诸如ARM架构下则是禁止的；Cacheline即CPU在处理数据时与内存映射地址进行通讯时的缓存通道，该通道起到预存数据的作用，同一个Cacheline的传输时延会下降)产生得特别多，Cacheline问题的不断上升触发了Cacheline一些限制措施，从而使得CPU使用被”压住“，导致无法充分发挥CPU性能调度GPU资源来实现渲染，关于该问题对于技术服务侧来说有更加方便的方式判断，也得益于众多阿里云先驱前辈的白屏化进程，使用内部系统可以直接将具体时间线输出明确对比黑屏时间：
基于这个判断，从底层宿主机看下是否存在一些基于Cacheline问题的限制，我们从当前case发现确实存在Cacheline问题的限制，所以就进行了一些限制解除的实验，最终确认了与Cacheline强相关，但是游戏厂商进程无法通过去壳手段来进行分析（也不在平台分析范围内），所以对于游戏进程产生的cacheline交由客户与游戏厂商继续分析，不过整体解除Cacheline限制后黑屏情况相较于优化性能后又再下一城。—— 这一点同时也是Log慢的核心原因
经过两轮的优化，从一开始平均1k+下降到600+，再到400+：
3.1.3、兼容性类排查
在解答这一点前，我们需要确认几个基础概念：
· 视频相关API：主要用于捕获、加速渲染等作用的API，N卡常见的有：微软提供的DDA(Desktop Duplication API)以及NV提供的NVFBC（NVIDIA® Frame Buffer Capture API）
· GRID：N卡的核心虚拟化技术，由NV开发与提供，也是N卡虚拟化主流的实现方式，包含前后端驱动，GRID11、12均为GRID的版本
· TDR：Timeout Detection & Recovery ，GPU的调度超时相关指标，默认应用程序请求GPU资源超过2s（可调）就会在日志中记录一条warning级的TDR，NVIDIA对此也有相关解释，从GPU配置程序入手配置的话可见链接
3.1.3.1、黑屏与TDR验证
了解完基础概念，这一点也是本次解决黑屏最重要的一点，如图2所示，驱动的兼容性是否有问题，这一点其实在专项介入早期就已经发现客户在使用解码、编码接口上用了较为老旧的NVFBC接口（NVFBC接口是NVIDIA提供的相关渲染接口，是厂商提供的特定功能接口，具体可点击链接查看，偏视频渲染领域），而在最新的Windows Server 2012+开始NV明确表示了不再支持。客户使用FBC接口方式也从客户的业务日志中有所发现：
其次，在客户反馈的黑屏时间段里存在大量的TDR：
所以接下来的排查重点就聚焦在：
· TDR与黑屏是否有直接关系
· DDA与FBC是否为黑屏的突破点
3.1.3.2、TDR Delay验证
验证第一个问题并不困难，通过对比没有黑屏的机器可以明确的看到没有TDR信息，同时客户自身采集的逻辑也包含了TDR数量的检测，在TDR数量少的情况下同等黑屏次数也很少，所以第一个问题基本得到验证，在第一part的图里也可以看到关于云游戏底层的IaaS逻辑是这样的：
当出现TDR时，意味着两种可能性，预期内的可能性是当时游戏负载较高，导致显卡响应不过来了，在3A类型的游戏大作中渲染超2s的情况不算多见，但是也会有，量级一般可控，量级大到导致黑屏的确实少见，而另外一种预期外的可能就是在运行时遇到了驱动级或者不可用的函数导致等待不到GPU控制器的回复产生的超时，为了验证这个理论，我们与GPU研发讨论后，进行了TDR Delay验证，即把TDR的阈值从2s调整为10s，可以参考以下指引：
3.1.3.2、切换DDA验证
调整TDRDelay后发现黑屏次数确实有两位数的下降，但总量依旧是在千级别，证明了客户业务确实存在TDR预期内的问题，但是不是黑屏的主因，很可能是因为预期外问题导致这些预期内的问题被放大，那么做了这个实验后就基本确认TDR问题聚焦在预期外问题，预期外问题刚好与排查重点2有重合，因为DDA与FBC模式且好是驱动层面中Rendering阶段核心的接口因素，基于此，我们开始了第二轮实验：对接口进行切换，从FBC切换成DDA观察，非常有幸的是，本来我们都准备拉齐研发资源帮客户做好切换的相关测试与验证，没想到客户集成了切换模式，切换成DDA成本很低，所以仅用时1天就完成了50%量从FBC切换DDA的操作，下图是完成后观察两天的结果，可以看到相对于FBC无论是次数还是发生频率都大幅下降了，基本上证明FBC为核心问题，而TDR为判断该问题是否解决的标志：
3.1.4、解决之道
现在我们经过多轮的验证与排查、观察，可以发现FBC，降低TDR是完成单台VM<100次黑屏的解决之道，但是解决仅仅是切换DDA即可吗？答案显然不是，虽然黑屏情况有了大幅提升，但是离客户的核心诉求依旧有一定差距（平均200+，目标<100），另外DDA是否有其他坑？答案是肯定的，切换DDA后，虽然黑屏减少了很多，但是编码采集慢问题有了线性增长，可以说为了解决黑屏问题却引入了次生问题，同时DDA接口是一个高度集成的接口，即Rendering+Encode是合在一起的，对于定位是具体什么链路导致的采集慢无法定位（后经过NV确认，DDA在微软侧已经确认了存在非预期采集慢问题，但是由于底层机密无法透露具体原因，只承诺在新版本会找解决方案，这就是一开始为什么提依赖于厂商链路的原因，依赖厂商相对可控性就低了，比较黑盒），所以解决方法只能往FBC上想，脑暴汇聚如下：
答案比较明显，在现有驱动版本的情况明确了在GRID12(图中A)下对于NVFBC、DDA均不支持，作为售后角色综合考虑客户侧业务情况（友商驱动在GRID9下运行正常）与业务线情况（友商步步紧逼，成本压力大），在当下上量节点，方案就仅剩余通过降级驱动来评估是否FBC情况能否有明显改善，权衡后与研发一同讨论，确认启动GRID11+NVFBC方案评估，这样即可以为NV去分析GRID12下FBC、DDA的异常问题争取时间，同时也不影响客户上量诉求，另外GRID11本身也比其他友商要高两个级别，在功能特性上有加分，若通过的话，该问题算是里程碑突破，当下立断，评估客户侧环境，确认采用20/80测试，将20%机器采用带有降级驱动的镜像进行重新部署，观察效果，经过两周观察再逐步拓展到全量，效果如下：
3.2、卡屏（RDP卡顿）问题
由于该问题非上量的核心卡点，同时与vGPU本身业务特性相关，与vGPU技术特性相关较少，所以将简单描述，RDP卡顿原因也比较多样，但是核心难点在于产生卡顿时也就意味着Guest OS基本处于即将不可达状态，无法有现场去排查具体原因，所以需要借助底层的一些手段来捕获卡顿时的状态，好在卡顿问题的几率比较大，复现难度较低，所以在客户前期反馈了几例后保留了其中一台作为分析，并通过抓Dump的方式（这一点需要看条件，大部分的平台支持从虚拟化层面捕获Dump）保留了相关core文件进行分析：
3.3、Log慢问题
Log慢问题核心是由于相关CPU资源被抑制后，本来相关Log收集器没有资源以供上传，导致相关请求排队导致，非核心原因也有资源不足的情况，由于Cacheline异常与资源不足的情况在3.1、3.2中已经做了详细描述，Log慢问题就仅用一张图来概述：
自然问题的解决之道就需要依赖于客户排查产生Cacheline异常的游戏进程后再进行优化。
3.4、编码采集慢问题
【此部分核心由 @玄陌 @高峰 两位大师主刀，感谢两位大师悉心指导】
该问题的核心解决主要依赖于微软提供的GPU分析器，要解决编码问题，首先要了解编码采集的过程，可以看到这里也是重度依赖于GPU的存储与提交Encode(Encode模块也在GPU中)
有笔者要问了，既然都是资源不足问题，那为什么编码慢问题要单拎出来讲，那是因为编码慢问题处理使用到了GPUView，GPUView是从事Windows Server vGPU排障必备（特别是OS内vGPU问题、业务问题）时，所以重点讲讲，那为什么会说是资源不足问题呢？请看下图：
从火焰图与上面的队列以及第二张图可以看到Encode的频率基本稳定，而copy engine的频率不稳定，所以可以判断Encode的慢可能体现在从Encode出来的数据阻塞在了处理流程中。那基本可以确认两种可能：
· 客户相关处理链路时序或排队机制安排可能存在问题，导致encode得多，但是copy得少，大量任务的encode导致GPU被持续占用
· GPU资源不足导致copy任务申请不到计算资源进而引发排队
经过客户手动优化（加上部分编码慢原因由于DDA产生，原因上文已讲述，不累述），目前该问题也基本优化完成。
Part4 餐后小点：总结
4.1 坑点总结
· 系统内：
o 游戏进程，最好有游戏发行线测试，在确认上架前的POC阶段加入游戏对于负载，特别是GPU负载的压力如何
o 驱动版本，老生常谈，合适的驱动版本 > 匹配的驱动版本 > 新版本驱动，特别是NV厂商，坑坑洼洼很多，很多问题换个前端驱动（所谓的后端驱动就是宿主机层面的虚拟化驱动）可能就解决了
o 游戏核心链路协议：DDA在某些特定游戏场景下有坑，采集慢，同时链路耦合度太高，不便于排查，但是对于新Guest OS版本友好（虽然在GRID 12上有坑），FBC是NV老牌接口，目前已确认废弃（对特定客户开放持续支持，比如本篇中的客户就是NV单向承诺了，所以才敢继续使用），但是其相关链路分开，不同链路间可打点位置多，对于游戏业务比较友好。
o 设备层面：从设备管理器看可以确认映射的虚拟显卡是否有被注册到OS内的PCI接口上，若有显示但是未能被正确识别则很可能是驱动问题；
· 系统外：
GPU硬件(更建议找虚拟化团队、硬件团队)：从从业经历来讲，GPU硬件应该是为数不多能够与内存故障相匹敌（如果相同基数的情况）的部件了，在本次专项中笔者做得最多的就是上宿主机、VM打nvidia-smi(VM内部看到得更多是进程对应的GPU损耗)，这个可以确认GPU是否存在掉卡以及显性的UCE错误，而对于GPU硬件故障也可以看对应宿主机或x86服务器上的具体message，看看是否有XID之类（有XID不一定是硬件故障，具体可参阅NV的XID列表）的报错：
o 软件层面（更建议找虚拟化团队、管控团队）：可以重点检查下vmem分配情况以及相关xml对应的pci设备是否正常，还有后端版本是否符合预期。
4.2、一些遗留
本篇中讲到，使用了降级驱动+FBC，那么这个路子真的是长久之计吗？
显然不是，更多要依赖于厂商去进行相关Debug（所以说依赖于厂商的最大问题就是很多sysbol都拿捏在厂商手里）以及显卡FA（硬件二次分析），好在这次也保留了部分现场进行了FullDump，目前也已升级到NV研发团队，相信不久的将来，能够把个位数的黑屏都消灭成0。
其次，Cacheline异常是否有排除其他客观因素的最优解？当前属于客户独占规格与集群，后续客户或许能排查出一些游戏特征与Cacheline异常的核心因素，届时利用这些数据，说不定在ECS的产品形态上是可以探索下“游戏专属集群”的产品模式，这点笔者也很期待。
4.3、说在最后
本篇仅针对4个比较具有代表性的排障点进行展开，其实还有N个问题点未一一道来，很多问题其实规模化之后会暴露（比如黑屏、采集慢问题），所以总体来说，专项上量过程中售后技术服务的介入还是很有必要的，毕竟无论是产研视角还是客户视角，抑或是业务线视角，总归要有个完全中立的技术角色来成为云游戏上量过程中的核心转轴角色，使得整个专项落地更优雅（至少不是脸着地），其中很多技术服务能力其实来自于与产研的合作，而vGPU的形态在业界阿里算走得比较前，纵观整个vGPU产品形态，笔者还遥记得笔者在做底层运维某个GPU巨佬跟笔者说的一句话“GPU VM这个产品还在探索阶段，很多未知的领域还在探索，要给多点信心”，所以也借此文，希望笔者能够在这个专项中为GPU产品形态亦或者是整个云游戏技术服务阶段起到抛砖引玉的作用。
