GPU技术支持-业务篇-问题排查思路

前言

转载请附上原文出处链接

稀土掘金本文链接：juejin.cn/spost/72395…

CSDN本文链接：blog.csdn.net/qq_43252610…

概述

本文为个人在平时排查问题时的思路总结，以下思路仅供参考。

由于本人为软件工程师，经验总结更倾向于软件思维。

思路

思路不复杂，对于很多人来说可能很简单，总结下来就一句话：

范围从大到小，不变中寻找变化，变化中总结不变

常用方法：对比法

排查问题过程中，用的最多的就是对比法。通过对比的差异性来缩小问题范围，定位到问题点。

例如：

• 异常、正常状态对比：正常情况和问题情况的各类状态对比。
• 同类、同型号产品对比：产品替换成同类型、同批次或者其他厂家类似产品，观察问题是否消失。
• 产品版本对比：不同软件、硬件版本对比，确定问题是否由某一版本的修改引入。

注意：存在设备替换、版本变更等状态变更时，尽量需要保持单一变量变更

出现时机：问题何时出现？

出现时机对一些情况下的问题排查有相当大的参考价值。

• 正常使用一段时间，问题突然出现：

  问题出现前是否存在某些状态变动，主要关注这些变动。

• 设备第一次使用就存在该问题：

  出现时机无参考价值，正常流程排查

影响范围：个例or共性？

看到一个问题，常常需要确认问题的影响范围。不同的影响范围侧重的排查方向和重心也不同：个例问题针对个例情况单独分析，在相似的环境中找不同；共性问题则需要在不同的复现环境、时机下总结复现问题时的共同点。

个例问题

个例问题指的是该问题在同批次、同型号设备仅一台（或者极少量设备）出现的问题。通常软件环境容易存在差异，也就容易存在个例问题。个例问题需要和正常设备对比寻找差异，在差异中定位问题。

如果需要找到根因，问题环境需要保留，则需要正向排查、使用其他环境尝试复现问题、设备中部分组件替换验证等等方法。

如果只需要解决问题，可以先对软件环境进行统一，如果软件环境统一后问题依然存在，可以考虑需要硬件介入排查。

共性问题

共性问题指的是问题在同型号、同批次设备中大量或者全部出现的问题。共性问题通常需要正向排查，首先确认问题大概范围，一步步缩小范围去定位问题。

共性问题也可以使用同类产品对比、产品版本对比来从侧面去缩小问题范围。

例如：

• 显示相关问题在硬件上可以替换显示器、线缆、显卡等设备验证。软件上可以更换显卡驱动版本验证。
• 图形应用运行问题在硬件上可以替换显卡设备验证。软件上可以运行同类应用对比、升级（降级）显卡驱动、替换窗口管理器等等方法验证。

问题概率：偶发or必现？

问题的出现概率，通常也代表着问题的排查难度。一般来说，偶发问题排查难度相对大，必现问题排查难度相对小。

偶发问题

偶发问题软件上需要保留问题复现时的状态信息（日志），跟未复现问题时的状态信息做对比（日志），找到其中的不同点，锁定大概的问题范围。

根据问题范围，尝试去做相关改动增大复现问题的概率，如果改动点能够增大复现概率，说明改动方向是正确的。后续理清原理之后，理论上也能通过相关修改把偶发问题变为必现问题。

如果日志对比无法发现异常点，也没办法去增大问题复现概率，通过上述的方法找不到问题的大概范围，可以考虑直接先做大范围的变动：例如更换硬件、更换系统等等方法，先从大的范围确认怀疑点。

必现问题

必现问题通常是正向排查，根据问题现有的报错、日志等等信息，确认问题范围，之后进一步确认问题点。

对比法同样适用于必现问题的排查，通过同类替换，尝试将必现问题变为不复现。从大的范围上锁定相关的可能问题点。

问题隔离：找到有效的变量组合

问题隔离简单来说就是想办法减少影响的变量。一步步剔除无关变量，将问题范围不断缩小，能够将问题局限在某一范围内。

比如某问题有变量A、B、C、D、E、F、G，其中变量E、G、F同时存在时，问题会发生。那么变量E、G、F就是有效的变量组合。

其实影响范围、问题概率的章节中已经在使用问题隔离的方法。下面举一个简单的例子来作说明：

• 问题现象：一台主机，运行某个游戏崩溃了

• 硬件变量：显卡、CPU、内存、硬盘

• 软件变量：游戏、操作系统、显卡驱动

• 缩小范围：

  1. 运行别的游戏，是否也会崩溃？（显卡驱动、操作系统不变）
  2. 使用别的操作系统运行游戏，是否也会崩溃？（游戏、显卡驱动版本不变）
  3. 使用别的版本的显卡驱动运行游戏，是否也会崩溃？（游戏、操作系统不变）
  4. ......

当通过缩小范围去掉其他无关变量，找到有效的变量组合后，整个问题的排查范围就已经缩小了，有利于接下来的问题排查。

变量拆分：进一步定位问题点

通过问题隔离的方法能找到有效的变量组合，那么如何深入下去进一步排查呢？

这个时候就需要对变量进行拆分，将变量拆分成不同的子变量，对子变量进行验证或者分析，进一步深入去缩小范围。

下面举一个例子来说明：

在某个视频解码应用的排查过程中，出现窗口中无图像显示问题，初步定位问题只和应用相关。

应用可以简单分成解码、上屏两个部分，相当于应用这个变量拆分出了解码、上屏两个子变量。接下来就需要对两个子变量进行验证。

应用-变量拆分：

• 子变量1：解码
• 子变量2：上屏

应用-变量验证：

• 解码验证：解码数据给到上屏时是否正常？将解码数据转存下来验证
• 上屏验证：上屏逻辑是否正常？使用简单图片上屏验证

转存的解码数据正常，使用简单图片上屏仍然无显示，确认问题在上屏逻辑中，继续对上屏的变量进行拆分，拆分为窗口创建、纹理绑定、上屏绘制几个子变量。

上屏-变量拆分：

• 子变量1：窗口创建
• 子变量2：纹理绑定
• 子变量3：上屏绘制

上屏-变量验证：

• 窗口创建验证：窗口创建是否正常？窗口是否正常显示
• 纹理绑定验证：纹理绑定是否有正确的返回值？返回值符合标准
• 上屏绘制验证：绘制部分是否正常刷新？绘制时的矩阵是否

最后定位问题在上屏绘制部分，绘制部分刷新逻辑有误，未能正常刷新。

实际问题举例

显示黑屏问题排查

客户反馈遇到开机后遇到屏幕黑屏无显示问题。按照文中的思路进行排查。

排查思路：

• 影响范围：共性问题

  据客户反馈使用同批次的主板、显卡，问题依旧存在

• 问题概率：必现问题

  每次开机均出现该问题

• 问题隔离：

  显示问题通常跟以下几个变量有关：显卡（强关联显卡驱动）、显示器、线缆

  验证1：其他变量不变，更换其他品牌显卡，问题依旧存在

  验证2：其他变量不变，更换其他品牌显示器，问题依旧存在

  验证3：其他变量不变，更换其他线缆，问题解决

该问题能够定位为线缆问题

应用闪退问题排查

客户反馈遇到应用闪退问题。按照文中的思路进行排查。

排查思路：

• 影响范围：共性问题

  据客户反馈使用同批次的主板、显卡，问题依旧存在

• 问题概率：必现问题

  每次应用启动均出现该问题

• 问题隔离：

  应用闪退问题通常跟以下几个变量有关：显卡（强关联显卡驱动）、应用、CPU、操作系统

  验证1：其他变量不变，更换其他品牌显卡，问题不存在

  验证2：其他变量不变，更换其他类似应用，问题不存在

  不需要进行下一步了，直接把变量控制在显卡、应用上面了

• 变量拆分：

  因为是软件报错问题，暂时不考虑显卡硬件上的问题，只对显卡驱动进行变量拆分

  显卡驱动：核内、3D

  同时应用层闪退能够使用GDB调试定位大概的问题点，使用GDB后定位问题在顶点数据相关部分，省去了应用中子变量的问题隔离步骤。

  应用：顶点数据读取、顶点缓冲区申请、顶点数据传输到显存

• 验证：

  显卡驱动部分比较繁杂，暂时不进行验证，先从应用层面入手

  顶点数据读取验证：顶点数据正常读取，和文件中存储的数据一致

  顶点缓冲区申请验证：应用申请的顶点缓冲区较多。对所有申请后返回的顶点缓冲区ID进行打印，发现后面一部分ID返回不符合规范。

  问题基本定位，顶点缓冲区申请失败导致运行应用后出现闪退。推测是显卡驱动存在一个最大的顶点缓冲区申请限制。

  回溯验证-应用：减少程序的顶点缓冲区申请，程序正常运行

  回溯验证-驱动：走读驱动代码，发现确实存在最大顶点缓冲区申请上限。超过上限时ID返回0。

• 解决方案：

  应用对顶点数据进行合批，减少需要申请的顶点缓冲区数量

该问题能够定位为应用问题，应用需要对异常返回值进行判断，而不是直接使用