Go 最细节篇｜pprof 统计的内存总是偏小？
The following article is from 奇伢云存储 Author 奇伢
Go 的内存泄漏
内存泄漏通常在 c/c++ 等语言常见，手工管理内存对程序猿的编程能力有较高要求。最常见的就是分配和释放没有配对使用。
Go 是一门带 Gc 的语言，内存分配位置由编译器推断是在栈还是堆上，内存分配完全由 Go 本身把控，程序猿无法介入。程序猿在前端触发分配，后端的 runtime 的 GC 任务则不断的回收内存，从而达到一个平衡。理论上是不存在常规意义的内存泄漏的。但在程序中，还是经常见到内存占用持续升高的场景，今天就是来分享这类场景的思考。
Go 的内存问题更多的是内存对象的不合理使用，比如一个全局的 map ，程序猿 A 不知什么原因持续往里面添加元素，从来不删。这就是一个典型的内存泄漏（或者叫做内存不合理占用）。也就是说，Go 的内存问题基本都是不合理的业务逻辑导致的。
一般来说，这类内存问题其实非常好排查，怎么排查？
使用 Go 自带的 pprof 工具。
运用 pprof 利器
导入 pprof 包即可，然后开启一个监听端口：
import "net/http"
import _ "net/http/pprof"
func main() {
// ...
go func() {
http.ListenAndServe("0.0.0.0:8080", nil)
}()
// ...
}
把程序运行起来，然后直接通过网络接口拿到 pporf 的数据，很方便。
go tool pprof http://127.0.0.1:8080/debug/pprof/allocs
登陆之后 top 就能看到堆栈：
root@ubuntu20:~# go tool pprof http://127.0.0.1:8080/debug/pprof/allocs
(pprof) top
Showing nodes accounting for 1468.90MB, 99.79% of 1471.93MB total
Dropped 22 nodes (cum <= 7.36MB)
flat flat% sum% cum cum%
1270.89MB 86.34% 86.34% 1468.90MB 99.79% main.main
198MB 13.45% 99.79% 198MB 13.45% encoding/base64.(*Encoding).EncodeToString
0 0% 99.79% 198MB 13.45% main.EncodeGid
0 0% 99.79% 1469.90MB 99.86% runtime.main
pprof 实现的原理其实很简单，就是分配释放的地方做好打点，最好就是能把分配的路径记录下来。举个例子，A 对象分配路径是：main -> fn1 -> fn2 -> fn3 （ 详细的原理可以参考文章：Go内存管理深度细节 ），那么 go 把这个栈路径记录下来即可。这个事情就是在 mallocgc 中实现，每一次的分配都会判断是否要统计采样。
pprof 统计到的比 top 看到的要小？
主要有几个重要原因：1）pprof 有采样周期；2）管理内存+内存碎片；3）cgo 分配的内存 。
pprof 统计到的比实际的小，最重要的原因就是：采样的频率间隔导致的。
采样是有性能消耗的。 毕竟是多出来的操作，每次还要记录堆栈开销是不可忽视的。所以只能在采样的频率上有个权衡，mallocgc 采样默认是 512 KiB，也就是说，进程每分配满 512 KiB 的数据才会记录一次分配路径。
// runtime/mprof.go
var MemProfileRate int = 512 * 1024
// runtime/malloc.go
func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
// ...
if rate := MemProfileRate; rate > 0 {
if rate != 1 && size < c.next_sample {
// 累积采样
c.next_sample -= size
} else {
// 内存的分配采样入口
profilealloc(mp, x, size)
}
}
// ...
}
所以这个采样的频率就会导致 pprof 看到的分配、在用内存都比实际的物理内存要小。
有办法影响到加快采样的频率吗？
Go 进程加载的时候，是有机会机会修改这个值的，通过 GODEBUG 来设置 memprofilerate 的值，就会覆盖 MemProfileRate 的默认值。
func parsedebugvars() {
for p := gogetenv("GODEBUG"); p != ""; {
// ...
if key == "memprofilerate" {
if n, ok := atoi(value); ok {
MemProfileRate = n
}
} else {
// ...
}
}
}
改成 1 的话，每一次分配都要被采样，采样的全面但是性能也是最差的。
Go 使用的是 tcmalloc 的内存分配的模型，把内存 page 按照固定大小划分成小块。这种方式解决了外部碎片，但是小块内部还是有碎片的，这个 gap 也是内存差异的一部分。tcmalloc 内部碎片率整体预期控制在 12.5% 左右。
Go 运行过程中会采样统计内存的分配路径情况，还会时刻关注整体的内存数值，通过 runtime.ReadMemStats 可以获取得到。里面的信息非常之丰富，基本上看一眼就知道内存的一个大概情况，memstat 字段详情（建议收藏）：
其中，内存的 gap 主要来源于：
heap 上 Idle span，分配了但是未使用的（往往出现这种情况是一波波的请求峰值导致的，冲上去就一时半会不下来）； stack 的内存占用； OS 分配但是是 reserved 的； runtime 的 Gc 元数据，mcache，mspan 等管理内存；
这部分可大可小，大家记得关注即可。
cgo 分配的内存无法被统计到，这个很容易理解。因为 Go 程序的统计是在 malloc.go 文件 mallocgc 这个函数中，cgo 调用的是 c 程序的代码，八杆子都打不到，它的内存用的 libc 的 malloc ，free 来管理，go 程序完全感知不到，根本没法统计。
所以，如果你的程序遇到了内存问题，并且没用到 cgo ，那么就可以快速 pass ，如果用到了，一般也是排除完前面的所有情况，再来考虑这个因素吧。因为如果真是 cgo 里面分配的内存导致的问题，相当于你要退回到原来 c 语言的排查手段，有点蛋疼。
一个实际的例子
来看一个有趣的例子分析下吧，曾经有个 Go 程序系统 top 看起来 15G，go pprof 只能看到 6G 左右，如下：
top 的样子：
[amy@centos7]$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
499174 service 20 0 19.2g 15.1g 6932 S 635.3 24.3 496911:01 testprog
pprof 看到的：
(pprof) top20
Showing nodes accounting for 6.08GB, 88.63% of 6.86GB total
memstat 看到的：
sys_bytes 1.6808429272e+10 // 16029 // 系统常驻内存，单位是 M
alloc_bytes 1.0527689648e+10 // 10040 // 分配出的对象，且使用的
heap_alloc_bytes 1.0527689648e+10 // 10040 // 堆上分配出来，且在使用的
heap_idle_bytes 4.272185344e+09 // 4074 // 堆上的内存，但是还没人用，等待被使用
heap_inuse_bytes 1.154125824e+10 // 11006 // 堆内存，且在使用的
heap_released_bytes 5.06535936e+08 // 483 // 释放给 os 的堆内存
heap_sys_bytes 1.5813443584e+10 // 15080.8 // 系统占用内存
stack_inuse_bytes 2.424832e+07 // 23 // 栈上的内存
stack_sys_bytes 2.424832e+07 // 23 // 栈上的内存
mcache_inuse_bytes 55552 // 0.05 // mcache 结构的内存占用
mcache_sys_bytes 65536 // 0.06 // mcache 结构的内存占用
mspan_inuse_bytes 1.87557464e+08 // 178.8 // mspan 结构的内存占用
mspan_sys_bytes 2.31292928e+08 // 220.5 // mspan 结构的内存占用
gc_sys_bytes 6.82119168e+08 // 650 // gc 的元数据
buck_hash_sys_bytes 3.86714e+06 // 3.6 // bucket hash 表的开销
other_sys_bytes 5.3392596e+07 // 50 // 用于其他的系统分配出来的内存
next_gc_bytes 1.4926500032e+10 // 14235 // 下一次 gc 的目标内存大小
上面案例数据可以给到我们几个小结论：
系统总内存占用 15+ G 左右； Go heap 总共占用约 15 G ，其中 idle 的内存还挺大的，差不多 4G； 说明有过请求峰值，并且已经过去了 mspan，mcache，gc 元数据的内存加起来也到 1G 了，这个值不小了； 下一次 gc 后的目标是 14 G，也就是说至少有 1G 的垃圾； pprof 采样到 6.86 G的内存分配，pprof top 可以看到 Go 的分配详情；
总结
Go 的内存问题好排查，用 pprof 能解决 99% 的问题； pprof 采样虽然比实际的分配要少，但不影响问题的排查，看最多的就行，有问题的会一直有问题； memprofilerate 可以影响到采样频率，但一般不建议配置； tcmalloc 的管理方式没有外部碎片，但是有内部碎片，整体碎片率控制在 12 %左右； heap 上的 Idle span 的内存，stack 的内存，runtime 本身结构体的内存，这些内存占用有时候也不小，值得关注； 一般我们不会把问题指向 cgo，除非你用到了 cgo 并且已经排除了所有其他方向；
END
go全栈开发框架bud，go语言中的ruby on rails
谢孟军：中国 Go 语言领军人创业第五年
想要了解Go更多内容，欢迎扫描下方👇 关注 公众号，回复关键词 [实战群] ,就有机会进群和我们进行交流~
分享、在看与点赞，至少我要拥有一个叭~