golang trace view视图详解

  目录

  trace view 视图简介

  在go代码里,我们可以通过trace.Start和trace.Stop方法开启和关闭trace统计,之后我们会得到一个trace文件,可以用go tool trace命令打开它·。

  go tool trace -http=:8080 trace799152559

  在浏览器的打开界面,可以看到trace view视图包含了几个维度的统计信息。

  view trace 和 goroutine analysis 都是时间线的视图,不过观看的角度不同,view trace 是从processor(Gpm模型中的p) 角度,goroutine analysis 则是从协程角度。

  接着是各种类型的profile 视图,包含Network,Sync block,syscall block,scheduler latancy ,这些都可以用于分析系统延迟。

  然后是用户自定义的埋点统计,由于本节主要是看原生的trace view视图含义,所以可以先略去这部分。

  接着是minimum mutator utilization的视图,它可以用于分析垃圾回收对应用程序的影响。因为协程在分配内存时,在某些条件下也会触发垃圾回收,这将导致这部分时间内,协程不能执行用户程序逻辑,所以这个视图能够看到cpu用了多少时间在执行业务程序,多少时间用于垃圾回收。

  接下来,我们仔细分析下各部分视图的含义。

  view trace

  如上图所示,整个view trace 分为两个部分,stats和procs部分。

  stats

  stats 部分统计了在时间线上协程,线程数量,以及堆栈大小的变化情况。

  当点击某个一栏数据时,还会显示统计详情,比如点击时间线上线程这一栏,

  如上图所示,trace view视图最下方会出现当前时刻,处于运行状态和系统调用状态的线程数量。

  procs

  stats部分比较好理解,我们再来看看procs部分,首先来看下GC这一栏。

  GC这一栏也就是视图中时间线上蓝色这一段表示程序在这段时间内,在进行垃圾回收。注意垃圾回收并不是全过程都会STW的,所以在GC这段时间,应用程序还是会对外提供服务的。并且点击蓝色区域,在视图下方还会显示GC开始的堆栈。

  注意: golang的垃圾回收除了定时扫描回收内存,还会在分配内存时,判断正在执行的协程是否需要执行垃圾回收逻辑,如果需要,则会执行gcStart的逻辑,mallocgc就是golang进行内存分配的函数,所以你可以看到图中的gc正是由于当前协程分配内存才触发执行的,并且同一时期,只能有一个协程执行gcStart逻辑。

  接着简单说下Network和syscall 事件,它们在时间线上的点都是解除阻塞时的时间点。

  然后来看proc这一栏,proc代表的是processor ,它数量一般与cpu核心数相同,也可以通过GOMAXPROCS 设置其数量,协程需要放到proc队里里进行调度执行,proc的时间线上显示的则是各个协程在其上的运行时间。放大trace视图后会看的更加明显。如下图所示:

  trace视图中,按w是放大,s是缩小,a是左移,d是右移。

  这里其实要特别注意的是Outgoing flow 并不是直接导致协程在p队列上被切走的事件,实际上导致协程被切走的事件是阻塞事件,Outgoing flow 指的是阻塞事件之后被唤醒的那个时候的事件埋点。

  实际上,当前的trace view 视图绘制的时间线不会对阻塞事件进行绘制,只会对EvGoUnblock 事件进行绘制(具体为啥这样设计,我也不知道了🙅🏻‍♀️)不过从协程离开p队列时的堆栈也足够说明协程被切走的原因了。

  goroutine analysis

  接着我们来看下trace文件中对协程信息的分析。

  点击goroutine analysis,出现下面的截图:

  左边是协程创建时候的堆栈,右边N 代码在这行代码上一共创建了多少个协程。随便选择一行点进去,可以出现下面的截图,

  如上图所示,有各种的profile graph,这里是对下面所有协程进行统一分析得到的graph图 ,分别是:

  Network Wait Time(网络调用时等待,直到数据可达时被唤醒)

  Sync Block Time(mutex,channel,wait.Group产生的阻塞)

  Blocking Syscall Time(系统调用产生的阻塞)

  Scheduler Wait Time(协程阻塞后被唤醒并不会立马执行,而是在队列里等待被调度,这个时间就是等待被调度的时间)

  而最下面的表格则是每个协程在这些维度上的消耗时间,这里要注意下两个gc相关的时间只有GC sweeping 才会阻塞协程 ,GC sweeping指的是协程在清除回收内存时的处理时间,而GC pause 指的是采样过程中整个gc的时长,这一列每个协程都是一样的。

  请注意,GC 过程中只有发送STW时才会让协程阻塞。

  profile graph

  关于trcace 分析数据 除了像刚刚的特定堆栈产生的协程做各种延迟维度的分析,trace界面还提供了一个看所有协程的延迟维度的profile graph, 两者的原理都是一致的,只是后者原数据多一些。

  拿其中一个维度Scheduler Wait Time的 graph举例:

  指向每个函数框的箭头都携带了一个时间,例如 273.31us,它代表 函数servserv.init.func1函数等待协程调度的等待时间,注意这个时间不包含它的子函数的时间。时间越大,函数框越大,所以,你在看此类的图的时候,找最大的框就能发现延迟所在。

  Minimum mutator utilization

  最后我们来看下Minimum mutator utilization 这个视图。这个视图能够观测到垃圾回收对应用程序的影响。

  如上图所示,纵坐标表示应用除gc外,占用cpu的比例。值越高,说明应用得到的cpu资源越多,gc影响越小,最大值是1表示100%得到cpu资源。图中,最后应用cpu占用率达到了100%,可以暂时不用去管gc方面的影响。如果发现图中cpu资源长时间不能涨上去,则说明程序受gc影响比较大,应该对gc进行优化,像下面这种情况就应该优化gc了。

  以上就是golang trace view视图详解的详细内容,更多关于golang trace view的资料请关注脚本之家其它相关文章!

  您可能感兴趣的文章: