查看原文
其他

Go 最细节篇|pprof 统计的内存总是偏小?

GoCN 2022-09-09

The following article is from 奇伢云存储 Author 奇伢




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 主要来源于

  1. heap 上 Idle span,分配了但是未使用的(往往出现这种情况是一波波的请求峰值导致的,冲上去就一时半会不下来);
  2. stack 的内存占用;
  3. OS 分配但是是 reserved 的;
  4. 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;
    1. 说明有过请求峰值,并且已经过去
  3. mspan,mcache,gc 元数据的内存加起来也到 1G 了,这个值不小了;
  4. 下一次 gc 后的目标是 14 G,也就是说至少有 1G 的垃圾;
  5. pprof 采样到 6.86 G的内存分配,pprof top 可以看到 Go 的分配详情;


总结


  1. Go 的内存问题好排查,用 pprof 能解决 99% 的问题
  2. pprof 采样虽然比实际的分配要少,但不影响问题的排查,看最多的就行,有问题的会一直有问题
  3. memprofilerate 可以影响到采样频率,但一般不建议配置;
  4. tcmalloc 的管理方式没有外部碎片,但是有内部碎片,整体碎片率控制在 12 %左右;
  5. heap 上的 Idle span 的内存,stack 的内存,runtime 本身结构体的内存,这些内存占用有时候也不小,值得关注;
  6. 一般我们不会把问题指向 cgo,除非你用到了 cgo 并且已经排除了所有其他方向;


END



-猜你想看-

go全栈开发框架bud,go语言中的ruby on rails

谢孟军:中国 Go 语言领军人创业第五年


想要了解Go更多内容,欢迎扫描下方👇 关注 公众号,回复关键词 [实战群]  ,就有机会进群和我们进行交流~

分享、在看与点赞,至少我要拥有一个叭~

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存