Golang的trace性能分析

一、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的频率

在这里插入图片描述

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

关注goroutine调度情况

鼠标放着不动,w是放大,s是缩小。一直放大可以查看具体goroutine的执行细节:
在这里插入图片描述

关注goroutine的数量

在这里插入图片描述

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

      下面这个就是GC过于频繁的例子。goroutine的调度还是不错的,有规律且密集
在这里插入图片描述

四、GC分析

当前服务GC情况

在这里插入图片描述

可以看到GC很频繁。查看监控发现,服务内存只用到了几十M.
在这里插入图片描述

这种情况只能手动改动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:
在这里插入图片描述

设置GOMEMLIMIT

程序中GOGC设置成3000,实际上内存利用率还是很低,只有200M,服务给定的资源是4G
在这里插入图片描述

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

效果如下:
在这里插入图片描述

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的。
在这里插入图片描述

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

在这里插入图片描述

标记阶段会将大概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列表。
在这里插入图片描述

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

点击查看goroutine,发现trace如下:
在这里插入图片描述

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

Scheduler wait耗时分析

大量的Scheduler wait如下:
在这里插入图片描述

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

end

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

铁柱同学

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值