[运营期间开发]卡顿处理--GPUView

这里写图片描述
开发期间的卡顿处理的方法比较多,可以打log等方法。

GPUView
在运营期间就是GPUView就是逆天的给力存在。
GPUView早先是一个微软实习生开发的东东(好逆天的实习生),以单独的方式来发布,后来集成到windows sdk中来,本blog上面这里有一些记录。
而且在后续GPUView依旧保持着发展,功能也越发好用了,连intel的gpa也在底层使用这个机制。

GPUView可以做的事情很多,其原理就是能够抓取一段时间的windows底层的消息(几乎所有你需要的消息),gpu driver,lock,context switch。。。应有尽有。这部分的抓取的applicaiton叫xperf.exe,看的时候是GPUView.exe,当然整个过程我们就简称GPUView了。
而且很棒的一点就是,windows自己会把这些消息缓存一段时间,然后在你抓取的时候,会把之前一段时间的信息拿过来,这对于抓取卡顿太妙了(其余的办法,你发现卡顿,但是这一帧已经过去了,你只能望卡兴叹)。

ps;我老婆认为这个软件太难看,我个人倒是挺喜欢这个hardcore的感觉,和windbg一样,解决问题简洁犀利。

GPUView使用
实际命令行什么的还是有点麻烦,抓取时候可以使用写好的一些GUI工具,在win10上面是这里
自己随便运行一个程序什么的,然后点击抓取,可以获得一个etl文件。

这里就举一个例子来说明过程:
1,有玩家反映在开封主城附件的豪宅区会有卡顿,于是qq上联系玩家,远程一下,收集到卡顿的etl文件。
2,然后使用GPUView.exe打开这个文件,遍历整个时间段里会发现有一个地方系统处于停滞:有近700ms都没有提交任何GPU命令
这里写图片描述
3,进一步zoom in,会看见主线程这里在忙,其他都在等,点击其中一个事件(这个是系统以一定间隔来采集执行的信息,点开可以看到进一步的callstack信息)
这里写图片描述
4,选择主线程,只选择Stack Walk,就可以看到这里的callstack了:
这里写图片描述
5,这个callstack,在自己有pdb的情况下就可以resolve出来,在gpuview的symbol path那里进行设置,就能看到具体的callstack了:
这里写图片描述
这时候就知道问题是出在什么地方了。

symbol解析问题处理
GPUView解析不出symbol的问题是经常出现的。
第一步可以做一些诊断:可以参见stackoverflow上面这个帖子
DBGHELP_DBGOUT = 1
DBGHELP_LOG = C:\dbghelp.log
通过这两个环境变量(就是系统环境变量的设置方法)可以把load symbol的过程log出来,实际windbg等一些系统工具都可以用这个办法诊断symbol不能resolve的问题。
通过log可以定位问题,比如我之前的问题就是改了symbol path,但是没有生效,还是到老的地方去找。
可能是gpuview在symbol path改变的生效方面的bug,于是就乱试好了,比如把这几个选项开开关关
这里写图片描述
然后就好了。
//2018.2.3更新
还发现一个情况就是,起作用的可以稳定搞定的操作是:

  • 写好路径,然后apply path,第一次一般不起作用(起作用的时候明显感觉到gpuview软件会卡一下)
  • 然后对路径做一个修改,比如把路径结尾的时候加一个”\”或者去掉(output->output\ 或者反过来)
  • 然后apply path,正常会有一个小卡顿,就意味着symbol resolve成功了
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值