A Wand Makes Your Ideas Come True

0%

Golang GC调优实战系列之一

本文记录了笔者在工作中遇到一个真实场景,在堆内存超过16G,堆对象过亿情况下,以真实案例带领读者感受不同参数设置情况下Go的GC性能变化。

背景

笔者所维护的服务在启动过程中需要加载一个巨大的词表到内存中,词条数量达到千万量级,加之其他辅助数据结构,堆对象数量达到过亿级别。

笔者开发机为16G内存,起初词表体积不大,在开发机可以顺利启动调试,随着词表不断加大,程序启动时所占用的内存已超出物理内存大小,导致程序无法启动(笔者没有开启交换分区)。

另一个有用的背景信息是,可以观察到程序在启动时所占用的内存是最大的,程序启动后,会逐渐将申请的内存归还给操作系统,并最终稳定在某个数值上,而这个最终稳定的数值大约是启动时峰值内存的60%左右。

根据上述现象,推断这是由于启动时垃圾回收不及时导致的,通过调节Go的垃圾回收控制参数,笔者成功控制了服务启动时所需要使用的内存大小。

核心代码

使用下述程序来抽象公司的业务逻辑,消费者从队列中读取序列化的数据,将其反序列化到一个临时的中间数据结构中,将变形后的数据写入map中保存,抛弃中间结果。可以想到,造成内存占用量大的问题在于这些临时的中间对象被抛弃后,没有及时被GC回收。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
package main

import (
"encoding/json"
"fmt"
"runtime"
"sync"
)

// 用于解码数据的临时结构
type QMessage struct {
ID uint64 `json:"id,omitempty"`
Body QMessageBody `json:"body,omitempty"`
}
type QMessageBody struct {
Field1 string `json:"field_1,omitempty"`
Field2 int `json:"field_2,omitempty"`
}

// 常驻于内存的数据结构
type Message struct {
id uint64
field1 string
field2 int
}

// 内存数据缓存,里面存放了千万级的词条信息
var buffer = make(map[int]Message)


func main() {
wg := &sync.WaitGroup{}
q := make(chan string)
wg.Add(2)
go producer(q, wg)
go consumer(q, wg)
wg.Wait()
PrintMemUsage()

}

// 模拟生产者,产生两千万词条数据
func producer(q chan string, wg *sync.WaitGroup) {
for i := 0; i < 20000000; i++ {
q <- `{"id":123456, "body":{"field1": "123", "field2": 456}}`
}
close(q)
wg.Done()
}

// 模拟消费者,消费并反序列化词条数据,使用中间临时数据结构进行数据变形,并将最后的结果存储
func consumer(q chan string, wg *sync.WaitGroup) {
idx := 0
for data := range q {
idx++
qtmp := QMessage{}
json.Unmarshal([]byte(data), &qtmp)

tmp := Message{
id: qtmp.ID,
field1: qtmp.Body.Field1,
field2: qtmp.Body.Field2,
}
buffer[idx] = tmp
}
wg.Done()
}

// 以下是打印内存监控数据的工具函数,与业务逻辑无关
func PrintMemUsage() {
var m runtime.MemStats
runtime.ReadMemStats(&m)

// For info on each, see: https://golang.org/pkg/runtime/#MemStats
fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
fmt.Printf("\tNumGC = %v", m.NumGC)
fmt.Printf("\tAllocObjCnt = %v", m.Mallocs)
fmt.Printf("\tSTW = %v\n", m.PauseTotalNs)

}

func bToMb(b uint64) uint64 {
return b / 1024 / 1024
}

调优&测试

Go为开发者只暴露了一个调节GC的参数,这个参数可以通过在启动Go之前指定环境变量GOGC来控制,他控制的是触发GC的阈值,是一个百分比。当Go新创建的对象所占用的内存大小,除以上次GC结束后保留下来的对象占用内存大小,所得到的比值大于GOGC设置的阈值时,就会触发一次GC。如果没有指定这个变量,则默认值是100。也就是说,默认情况下,当目前占用内存是上次GC结束后占用内存的一倍时,才会触发一次GC。

我们的优化思路到这里很明显了:

  • 降低触发GC的阈值,避免等待GC的对象占用过多的内存
  • 降低阈值势必增加GC的次数,那么需要对GC次数增加带来的性能损失做一下评估

为了测试不同GC阈值情况下,程序的性能表现,我们使用下面的脚本来批量测试不同情况下的程序性能:

1
2
3
4
5
6
7
go build -o a.run main.go 
data=( -1 12 25 50 100 200)
for i in ${data[@]} ; do
echo "==== start", GOGC=$i "===="
GOGC=$i time -p ./a.run
echo
done

调优数据分析

测评数据如下表所示,第一行GOGC=-1表示禁止完全GC,第二行GOGC=12表示新分配对象占用内存超过上次GC后程序占用内存的12%时会触发一次新的GC。

GOGC 物理内存占用 程序执行时间 用户态CPU时间 内核时间 GC次数 GC STW时间
-1 9165 MB 38.52 s 37.01 s 5.25 s 0 0
12 1507 MB 39.04 s 66.31 s 3.30 s 223 14168116 ns
25 1494 MB 37.58 s 51.11 s 3.33 s 121 7355709 ns
50 1623 MB 36.76 s 44.30 s 3.15 s 65 3817951 ns
100 4188 MB 37.50 s 40.94 s 4.27 s 31 1653426 ns
200 4062 MB 37.73 s 40.37 s 4.46 s 20 1062916 ns

观察表格,我们可以有以下几个结论(不一定严谨,但从数据上看大方向是对的)

  • 对比前两行,即完全禁用GC和开启GC的情况,可以看到,我们的代码大约产生了7.5G的中间对象
  • 对比GOGC=12GOGC=100两行,可以看到,经过调优的内存消耗降到了默认设置的大约三分之一
  • 观察GC STW时间GC次数两列,可以发现,Go使用三色标记算法的GC Stop The World停顿时间还是非常短的。
    • 可以在上述程序中增加打印m.PauseNs来观察每次gc停顿的耗时,基本每次停顿时间不会超过100微秒,也就是0.1毫秒
  • 观察程序执行时间用户态CPU时间,可以发现,增加GC次数后,程序执行的耗时没有明显增加,但CPU时间增长很多。
    • 说明GC的扫描过程充分利用了多核的优势,GC的主体过程并不会明显block用户逻辑的执行。
    • 从这一点可以加深对Go GC不同阶段的理解。Go的GC只需要在首尾两个很短的环节中引入StopTheWorld的停顿,而其他大部分GC的时间都是与用户逻辑并行的
    • 如果你的机器有充足的空闲CPU时间给GC任务使用,则对用户逻辑的影响很小
  • 关闭GC后,按照我们的直观理解,减少了GC的次数,应该执行耗时更短才对,不过通过观察上表可以看出,关闭GC后,内核时间消耗明显增加,同时程序运行时间并没有缩短,甚至比打开GC还要长。
    • 我们可以粗略认为这是由于Go的运行时需要找操作系统分配更多内存导致的。
      • 上述数据跑在16G内存,并且打开交换分区的机器上,机器上同时还运行着其他的应用,关闭GC后占用9G内存,操作系统内核极有可能动用了交换区,进一步拖慢速度
    • 另一方面,由于每个对象都要占用新的内存,导致CPU的Cache命中率降低,也会拖慢运行速度。

结论

通过上述数据分析,我们最终选择了设置GOGC=50,该取值可以在GC消耗与内存消耗之间取得较好的平衡。

微信公众号:极客幼稚园
关注阅读更多优质技术文章