Golang的trace性能分析

文章目录

    • 一、trace概述
    • 二、trace的使用方式
      • 代码中trace采集
      • 通过pprof采集
    • 三、trace分析细节
      • trace的web界面
      • trace中需要关注的
        • 关注GC的频率
        • 关注goroutine调度情况
        • 关注goroutine的数量
        • 理想情况
    • 四、GC分析
      • 当前服务GC情况
      • 设置GOGC
      • 设置GOMEMLIMIT
      • GC阈值的讨论
        • GC的特点
    • 五、goroutinue分析
      • goroutine概览
      • Sync block耗时分析
      • Scheduler wait耗时分析

一、trace概述

      上一篇是pprof的性能分析,通过pprof找到我们服务中的瓶颈点来进行优化。Golang的pprof性能分析

      一般我们使用pprofprofile来分析服务的性能,主要是CPU方面的耗时和调用链路等。但是光靠profile是不够的,细节方面还是要使用trace分析并发和阻塞事件,goroutine的调度和GC情况。

相比profile,通过trace我们能看到什么呢?

1、程序运行中的goroutine数量分布
2、GC的频率和Heap的占比
3、goroutine的调度和运行,阻塞情况

二、trace的使用方式

代码中trace采集

import (
    "os"
    "runtime/trace"
)

func main() {
    trace.Start(os.Stderr)
    defer trace.Stop()
}

// 生成trace
go run main.go 2> trace.out

通过pprof采集

// trace采样
浏览器下载: http://127.0.0.1:6060/debug/pprof/trace?seconds=20
命令行采样: curl http://127.0.0.1:6060/debug/pprof/trace\?seconds\=20 > trace.out

// 运行采样的trace文件,会自动打开浏览器页面
go tool trace trace.out

三、trace分析细节

trace的web界面

参考:Go 大杀器之跟踪剖析 trace

https://eddycjy.gitbook.io/golang/di-9-ke-gong-ju/go-tool-trace

View trace:查看跟踪
Goroutine analysis:Goroutine 分析
Network blocking profile:网络阻塞概况
Synchronization blocking profile:同步阻塞概况
Syscall blocking profile:系统调用阻塞概况
Scheduler latency profile:调度延迟概况
User defined tasks:用户自定义任务
User defined regions:用户自定义区域
Minimum mutator utilization:最低 Mutator 利用率

trace中需要关注的

关注GC的频率

Golang的trace性能分析_第1张图片

      GC的频率过大,会导致大量的资源用于GC阶段,影响程序性能。另外要关注Heap的释放情况,Heap经过GC之后不释放那就需要关注内存泄漏问题了。内存泄漏大部分是查看goroutine释放和服务占用内存情况,可以参考Golang的pprof性能分析

关注goroutine调度情况

鼠标放着不动,w是放大,s是缩小。一直放大可以查看具体goroutine的执行细节:
Golang的trace性能分析_第2张图片

关注goroutine的数量

Golang的trace性能分析_第3张图片

理想情况

1、GC次数适中,要多或者太小都不行
2、goutinue数量不会突增或者持续增加
3、goroutine的调度密集且有规律

      下面这个就是GC过于频繁的例子。goroutine的调度还是不错的,有规律且密集
Golang的trace性能分析_第4张图片

四、GC分析

当前服务GC情况

Golang的trace性能分析_第5张图片

可以看到GC很频繁。查看监控发现,服务内存只用到了几十M.
Golang的trace性能分析_第6张图片

这种情况只能手动改动GC的阈值了。

GOGC 变量设置初始垃圾收集目标百分比。当新分配的数据与上次收集后剩余
的实时数据的比率达到此百分比时,将触发收集。
默认值为 GOGC=100。

比如上次gc之后剩余10M,那么下次GC的阈值就是10M+10*100% = 20M

设置GOGC

// 调整gc阈值的源码
func readGOGC() int32 {
	p := gogetenv("GOGC")
	if p == "off" {
		return -1
	}
	if n, ok := atoi32(p); ok {
		return n
	}
	return 100
}

设置环境变量GOGC,然后查看trace:
Golang的trace性能分析_第7张图片

设置GOMEMLIMIT

程序中GOGC设置成3000,实际上内存利用率还是很低,只有200M,服务给定的资源是4G
Golang的trace性能分析_第8张图片

GOMEMLIMIT : 设置GC的阈值(go 1.19提供),设置为服务限定资源的一半
GOGC=off : 关闭自动GC。

效果如下:
Golang的trace性能分析_第9张图片

GC阈值的讨论

参考:官方对于GC的详细解释

GC的特点

1、当 GC 在标记和清除阶段之间转换时,短暂的 stop-the-world 暂停,
2、调度延迟,因为在标记阶段GC占用了25%的CPU资源,
3、用户 goroutines 协助 GC 响应高分配率,
4、当 GC 处于标记阶段时,指针写入需要额外的工作,并且
5、运行的 goroutines 必须暂停以扫描它们的根。

      过多的GC会占用CPUgoroutine的资源。但是过少的GC会导致每次GCstw时间变长,因为要标记和清楚的内存过多。因此GC阈值设置多大,也是个选择题。

五、goroutinue分析

参考:Golang GC核心要点和度量方法

goroutine概览

      通过放大可以看到,goroutine的状态,有Dedicated的,有Idle的。还有处于mark标记状态的,有sweep的。
Golang的trace性能分析_第10张图片

      GC的三个主要阶段:mark(标记)、sweep(清扫)和 scan(扫描)。好了,跟八股文完美对上了。
红框中还有大名鼎鼎的STW

Golang的trace性能分析_第11张图片

标记阶段会将大概25%(gcBackgroundUtilization)的P用于标记对象,
逐个扫描所有G的堆栈,执行三色标记,在这个过程中,所有新分配的对象
都是黑色,被扫描的G会被暂停,扫描完成后恢复,这部分工作叫
后台标记(gcBgMarkWorker)。
这会降低系统大概25%的吞吐量,比如MAXPROCS=6,那么GC 
P期望使用率为6*0.25=1.5,这150%P会通过专职(Dedicated)/
兼职(Fractional)/懒散(Idle)三种工作模式的Worker共同来完成。

Sync block耗时分析

      从tracegoroutine analysis 点进去查看主要的goroutine列表。
Golang的trace性能分析_第12张图片

点进去就可以查看具体的goroutine执行情况。
在这里插入图片描述

点击查看goroutine,发现trace如下:
Golang的trace性能分析_第13张图片

      看起来146210这个goroutine进入了专职Dedicated GC处理工作模式。查看几个Sync block耗时比较长的发现都是在GC的时候,goroutine开始处理GC而暂停处理业务,等GC结束才会继续执行业务。 在优化过GC之后,Sync block耗时大幅度下降。

Scheduler wait耗时分析

大量的Scheduler wait如下:
Golang的trace性能分析_第14张图片

      关于调度,我们都知道GoGMP模型的调度,那么P的大小和goroutine的数量都会影响到调度性能。推荐使用uber的自动设置GOMAXPROCS的库。
uber开源的自动设置maxprocs的库
注意: 在服务分配的CPU不足1核的情况下,使用automaxprocs没什么提升。反而在多核的情况下,需要通过这个库来设置最佳的GOMAXPROCS

end

你可能感兴趣的:(golang,golang,后端,性能优化)