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産品形态亦或者是整個雲遊戲技術服務階段起到抛磚引玉的作用。