《泛娱乐行业技术服务白皮书》——三、泛娱乐典型业务架构与场景——3.2 游戏类泛娱乐——3.2.2 游戏泛娱乐技术服务（8） https://developer.aliyun.com/article/1230985?groupCode=supportservice
3.2.2.3.4 排障思路
•采集编码慢问题
上图是黑屏中做的所有排查方向，核心的主线分为三类： -OS内部问题——系统 (Guest OS)态 - 平台侧问题——底层(包含宿主机)相关 - 应用态问题——客户自身实 现的应用或最终玩家等其他平台不可控因素
黑屏问题的难度在于造成黑屏的原因太多了，或者说任一类问题造成的表象都可 能包含渲染黑屏，要解决黑屏问题首先的理解，黑屏是怎么产生的，屏幕画像的产生
来源于底层渲染计算生成的画面通过解码、封装、捕获等方式呈现出来，一旦出现异 常，最先怀疑的就是渲染计算的情况，所以对于黑屏：
•系统态排查
我们首先确认了当时系统内相关资源的使用率情况，发现都比较高，特别是 CPU资源与GPU资源方面，因为GPU的调度是需要利用CPU资源的(比如队列处理等 )，而游戏本身占用的CPU可能会很高(特别是3A大作)，所以当CPU负载较高时会导 致GPU调度不了，形成了成像失败，最典型的情况就是CPU负载很高，GPU负载不 高，通过渲染类连接(比如调用了GPU的VNC界面)看是黑屏状态，但是通过RDP协议 访问却只是卡顿(因为CPU分配不足)，这就是第一个系统态异常的怀疑点，下图为 GPU满是最终玩家感觉到黑屏时的任务管理器界面：
通过ProcessExplorer可以看到更具体占用GPU的情况：
通过对应进程获取相关堆栈信息，下图为CPU满时导致的黑屏与RDP卡顿(关于 RDP卡顿将在RDP卡顿中详讲)问题可以看到前面9core(客户使用的VM为定制版的9core)全部被对应游戏进程占了80%左右：
针对这种情况，建议根据排查出的游戏进程进行优化即可。
平台侧排查
关于第二点，前面说过，CPU使用率是云游戏场景中比较重要的指标，若有其他非 主观因素影响了CPU的使用也会导致黑屏几率上升，通过分析宿主机记录的Cache- line相关计数情况， 我们发现该客户云游戏VM的cacheline(当执行原子操作地址未对 齐时就会跨越两个cacheline进行传输，在Intel架构中将这种现象的量级定义为split- lock，而原子地址没对齐的场景，在Intel架构下是允许的，在诸如ARM架构下则是禁 止的；cacheline即CPU在处理数据时与内存映射地址进行通讯时的缓存通道，该通 道起到预存数据的作用，同一个cache 1 line的传输时延会下降)产生得特别多， Cacheline问题的不断上升触发了Cacheline一些限制措施，从而使得CPU使用被”压 住“，导致无法充分发挥CPU性能调度GPU资源来实现渲染，关于该问题对于技术服 务侧来说有更加方便的方式判断，也得益于众多阿里云先驱前辈的白屏化进程，使用 内部系统可以直接将具体时间线输出明确对比黑屏时间：
从底层宿主机看下是否存在一些基于Cacheline问题的限制，我们从当前case发 现确实存在Cacheline问题的限制，所以就进行了一些限制解除的实验，最终确认了 与Cacheline强相关，但是游戏厂商进程无法通过去壳手段来进行分析(也不在平台 分析范围内) ， 所以对于游戏进程产生的cacheline交由客户与游戏厂商继续分析， 不过整体解除Cacheline限制后黑屏情况相较于优化性能后又再下一城。 —— 这一 点同时也是Log慢的核心原因
在某个案例可以看到经过两轮的优化，从一开始平均1k+下降到600+，再到
400+：
兼容性类排查
在解答这一点前，我们需要确认几个基础概念：
•视频相关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.2 游戏类泛娱乐——3.2.2 游戏泛娱乐技术服务（10） https://developer.aliyun.com/article/1230983?groupCode=supportservice
