Go 最细节篇｜pprof 统计的内存总是偏小？

发表于 2年以前 | 总阅读数：666 次

坚持思考，就会很酷

Go 的内存泄漏

内存泄漏通常在 c/c++ 等语言常见，手工管理内存对程序猿的编程能力有较高要求。最常见的就是分配和释放没有配对使用。

Go 是一门带 Gc 的语言，内存分配位置由编译器推断是在栈还是堆上，内存分配完全由 Go 本身把控，程序猿无法介入。程序猿在前端触发分配，后端的 runtime 的 GC 任务则不断的回收内存，从而达到一个平衡。理论上是不存在常规意义的内存泄漏的。但在程序中，还是经常见到内存占用持续升高的场景，今天就是来分享这类场景的思考。

Go 的内存问题更多的是内存对象的不合理使用，比如一个全局的 map ，程序猿 A 不知什么原因持续往里面添加元素，从来不删。这就是一个典型的内存泄漏（或者叫做内存不合理占用）。也就是说，Go 的内存问题基本都是不合理的业务逻辑导致的。

一般来说，这类内存问题其实非常好排查，怎么排查？

使用 Go 自带的 pprof 工具。

运用 pprof 利器

1 开启 pprof 端口

导入 pprof 包即可，然后开启一个监听端口：

import "net/http"
import _ "net/http/pprof"

func main() {
    // ...
    go func() {
        http.ListenAndServe("0.0.0.0:8080", nil)
    }()
    // ...
}

2 pprof 排查姿势

把程序运行起来，然后直接通过网络接口拿到 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

3 pprof 原理其实很简单

pprof 实现的原理其实很简单，就是分配释放的地方做好打点，最好就是能把分配的路径记录下来。举个例子，A 对象分配路径是：main -> fn1 -> fn2 -> fn3 （详细的原理可以参考文章：[Go内存管理深度细节] ），那么 go 把这个栈路径记录下来即可。这个事情就是在 mallocgc 中实现，每一次的分配都会判断是否要统计采样。

pprof 统计到的比 top 看到的要小？

主要有几个重要原因：1）pprof 有采样周期，2）管理内存+内存碎片，3）cgo 分配的内存。

1 pprof 有采样周期

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 的话，每一次分配都要被采样，采样的全面但是性能也是最差的。

2 内存有碎片率

Go 使用的是 tcmalloc 的内存分配的模型，把内存 page 按照固定大小划分成小块。这种方式解决了外部碎片，但是小块内部还是有碎片的，这个 gap 也是内存差异的一部分。tcmalloc 内部碎片率整体预期控制在 12.5% 左右。

3 runtime 管理内存

Go 运行过程中会采样统计内存的分配路径情况，还会时刻关注整体的内存数值，通过 runtime.ReadMemStats 可以获取得到。里面的信息非常之丰富，基本上看一眼就知道内存的一个大概情况，memstat 字段详情（建议收藏）：

其中，内存的 gap 主要来源于：

heap 上 Idle span，分配了但是未使用的（往往出现这种情况是一波波的请求峰值导致的，冲上去就一时半会不下来）；
stack 的内存占用；
OS 分配但是是 reserved 的；
runtime 的 Gc 元数据，mcache，mspan 等管理内存；

这部分可大可小，大家记得关注即可。

4 cgo 分配的内存

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 的目标内存大小

上面案例数据可以给到我们几个小结论：

1 . 系统总内存占用 15+ G 左右；

2 . Go heap 总共占用约 15 G ，其中 idle 的内存还挺大的，差不多 4G；

a . 说明有过请求峰值，并且已经过去了

3 . mspan，mcache，gc 元数据的内存加起来也到 1G 了，这个值不小了；

4 . 下一次 gc 后的目标是 14 G，也就是说至少有 1G 的垃圾；

5 . pprof 采样到 6.86 G的内存分配，pprof top 可以看到 Go 的分配详情；