• 概述
• ETW技术架构
• Data Table
• WPA使用步骤
• 各种Event Provider一览
• 分析CPU相关
  • Power/CPU Idle States
  • Power/CPU Frequency
  • Computation/CPU Usage (Sampled)
  • Computation/CPU Usage (Precise)
• 分析UI卡顿

概述

基本过程：WPA是辅助WPR使用，WPR（Windows Performance Record）用来录制ETL（包括CPU使用率、IO、文件、网络、GPU、堆等），借助ETW技术框架实现，WPA用来可视化分析ETL文件。
基本使用方法：拖拽、右键选择
基本展示内容：各种维度的统计数据，可选择总和、平均、最大、最小等各种统计方法，也可选择UI延迟、CPU占用、文件读写耗时等各种维度数据

一个特点：灵活，丰富的内容需要根据各种不同场景灵活选择处理，以便尽可能快的定位问题

ETW技术架构

Controllers：启动和停止Events发送，以及log路径和大小设置，以及Provider的选择允许。WPR（Windows Performance Record）就是一个Controller。它会使用StartTrace等API

Providers：不同类型的Event产生者。例如线程、网络、IO、内存等各种Provider。它会使用WriteEvent

Consumers：使用Event的使用者。WPA就是使用者，用来做可视化分析。它会解析log file

Data Table

灵活处理用各种不同维度做主key，来统计数据，需要了解两根线条（黄线蓝线）的含义

Key Area：用这一组维度数据作为统计关键字，通常需要正确搭配，例如Process可以搭配Thread

Data Area：数据统计区，这里可以是消耗时间cost time、次数等

Graphing element Area：绘制区，这里可以是时间间隔during time、权重占比Weight等

WPA使用步骤

Step1：打开ETL文件
Step2：选择要分析的图形属性，例如是要分析CPU占用？磁盘存储？界面卡顿UI Delay？网络？内存使用？
Step3：选择一个时间区间（通常是肉眼观察到的数据波形有问题的区间段）
Step4：放大Zoom
Step5：定制要分析观测的数据Data Table维度

各种Event Provider一览

通过System Configuration - Trace Statistic，可以看到有非常多的各种不同的Provider

分析CPU相关

CPU执行的基本单元是线程，线程有三种状态：wait（不可执行且未运行，需要SetEvent或者timer到来）、ready（可执行但未运行，等待执行线程的时间片消耗完）、running（可执行且正在运行）。当然，影响这三个状态的，还有线程优先级，处于ready状态下的高优先线程，会比处于ready状态下的低优先级线程先执行。Foreground Windows线程优先级会被动态提升得很高，且时间片分配得更多。

硬件设备与CPU交互的方式，是中断。当发生中断的时候，当前running的线程会被挂起，然后切换到中断服务线程，执行中断响应。当正在执行中断响应的时候，会阻止其他任何形式的线程切换，中断服务会一直保持执行完成。基于中断服务是原子级别的，这就要求中断服务的执行必须快速完成。为了降低中断执行时间，通常会抛一个DPCs调用，放到系统的DPCs队列，优于其他线程执行，但是能保证中断的切换执行。由于这个高优先级原因，也会影响性能点，可能导致其他线程的执行受到延迟。

如果线程处于同步等待，会影响性能，可能不能充分利用多个CPU核，另外UI线程如果同步等待，会导致UI线程卡顿，界面绘制卡顿。

与CPU相关的视图，有很多个

Power/CPU Idle States

主要是分析CPU每个核心的空闲状态。如果对于一个后台服务，需要CPU尽可能跑满，这里CPU空闲态应该尽可能少。如果分析一个笔记本的CPU运转模式，应该使得空闲尽可能多，尽可能进入省电模式。

Power/CPU Frequency

主要分析CPU每个核心的运转频率情况。之所以频率可变，是因为P-State（Performance）和T-State（Throttle ）机制。这里曲线表示的是P-State的频率变化，常规状态下是一条直线，如果发生变化，就是可能有多重不同的P-State在做切换。

Computation/CPU Usage (Sampled)

每1ms对CPU的每一个核做一次采样，获取对应的进程、线程执行情况，统计出执行次数和时间。因为采样间隔为1ms，其实很长了，很多DPCs和ISRs是非常短的，可能都无法采样到。另外，这里由于CPU的状态切换，所以采样计算到的时间并不一定精确，其中weight都是直接采用当前采样时间减去上一次采样时间的。其中分为如下几个子视图：
Utilization by CPU：描述了每个CPU核上跑了哪些任务
Utilization by Priority：描述了高优先级的如何影响低优先级的任务，以及不同优先级任务执行情况
Utilization by Process：描述了哪些进程占用了更多的CPU
Utilization by Process and Thread：描述了哪些进程的那些线程占用了更多的CPU
Utilization by Process，Stacks：描述了进程的哪些栈帧对CPU有更高的占用。这里不同线程可能调用同一个api，有相同的栈帧。
Utilization by Process，Thread，Stacks：描述了进程的哪些线程的哪些栈对CPU有更高的占用
DPC and ISR Usage by Module，Stack：描述了DPC和ISR的原子级别对CPU的占用，某模块（驱动模块）的栈帧级别的CPU占用。过多的占用也是性能影响点之一。

Computation/CPU Usage (Precise)

精确记录了上下文切换的情况，特别适合用于分析父子关系链，追溯源头。例如发现某个线程栈帧大量占用CPU，但是这个不是主动触发的，触发的场景又非常多，需要精确定位到是谁，就需要用这里的精确统计，记录的上下文切换情况来分析看待。
上下文线程切换的事件序列如下图：

几个概念： New thread：线程切换刚切换进来的线程，也是当前采样点所在的线程，通常以它作为分析核心，围绕着谁把它拉起来的来分析。
NewPrev thread：New thread的上一次切入进来的时刻状态
Readying thread：这个就是唤醒New thread的线程，也可以认为是父关系的线程。这个和New thread常用来作为核心分析对象，指明谁拉起了某个线程（SetEvent之类的，或PostTask之类的）
Old thread：当新线程被切换进入之前被切换出去的线程，这个看起来没啥价值。

在这个视图中，可以看到任意有关上下文的信息。比如将当前线程拉起来的Reading Thread的详细调用栈、起始函数、模块、以及线程退出的原因等等。

（1）Timeline by CPU：标识了每一个CPU核心的整个时间片的消耗序列
（2）Timeline by Process, Thread：进程线程的生命周期。比如有时候分析UI卡顿，在卡顿的那段时间Zoom，可以查看这段时间点的进程在干嘛
（3）Usage by Priority at Context Switch Begin：不同优先级的任务分布
（4）Utilization by CPU：不同CPU核的进程线程切换状态分布
（5）Utilization by Process, Thread：进程线程维度的详细唤醒分布等

剩下其他的，就自由发挥了

分析UI卡顿

首先看UI Delay的情况：

可以看到该进程有3个线程，每个线程分别卡了4s。这种情况，需要怀疑下是否死锁。再看CPU消耗情况：

当UI卡的时候，对应进程的CPU消耗为0，这说明卡顿现象，不是UI线程高计算任务导致的。既然跟CPU无关，那可能是在进行同步等待操作，或者死锁之类的。同步等待操作可能是正在进行文件的操作。先怀疑下IO，来看下IO的影响：

找了一遍，并没有对应进程的文件IO的消耗。再看下磁盘IO，发现也没有

那理论上来说，至少应该跟这些无关才对？回到刚刚CPU的情况，发现一个问题，所有对应的卡顿的UI线程，在CPU消耗里，一个都没有，应该是由于各种sleep或者wait，当前线程挂起，执行权交给别的线程了。那么就来看一下这些挂起的线程的生命周期，以及结束运行时的调用栈：

我的机器，加载符号有问题。这里大概知道是Win10这种AppCore内某个api的性能问题（内部可能大量的同步等待等等）。