Go 内存泄漏排查实战

现象

NumGoroutine 指标持续上涨，且低峰期未下降，判断出现了 Goroutine 泄漏现象。

排查

1. 通过访问线上服务 pprof 暴露出来的 HTTP 接口，拿到当前所有协程的堆栈信息；curl http://「ip:port」/debug/pprof/goroutine?debug=2

2. 发现存在大量存活时间超过上千分钟的 Goroutine，观察堆栈疑似是 http 连接未释放导致，通过对下图 net.sockets.tcp.inuse（正在使用的tcp socket数量）指标的观察进行了进一步的确认；

结论

http

下面以本次 case http 服务为例，做简单介绍：

• 上游服务作为客户端使用了 http1.1 并且将连接设置为 keepalive；
• 本服务作为服务端未设置 idletimeout 与 readtimeout；

当这两种情况同时发生时，如果上游持有对本服务的连接不进行释放，那么服务端会一直维持这个连接的存在，不进行回收，进而导致协程泄漏；

client上游客户端可能为 GO、Java 等，以下为 GO 语言 http 客户端的空闲连接超时设置；server解决建议启动 http server 尽量用后者，前者虽然简单，但是服务不够健壮；

thrift

server

Tips

需要注意的一点是，这个 Goroutine 泄漏问题不止在 http 下会发生，在 thrift、grpc 中也是同样的道理，如果服务端不对连接设置 timeout，某些情况下就会被上游拖死。

Reference

一起 goroutine 泄漏问题的排查^[1]

例2：内存居高不下

现象

内存使用量（mem.rss）居高不下，且低峰期未下降，怀疑发生了内存泄漏现象；

排查

1. 刚开始怀疑时内存泄漏，但是抓取 pprof heap 图观察后，未发现泄露问题，且内存分配符合预期；
2. 发现内存使用虽然居高不下，但未呈上涨趋势，因此修改关键字为“go 内存占用居高不下”，发现有相同问题；

结论

问题来自于 GO 在将内存归还给操作系统时的内存释放策略，详情见官方 issues^[2]，以下做简单介绍。

GO 内存释放策略

（此节内容整理自 压测后go服务内存暴涨^[3]）

不同策略的释放机制

• MADV_DONTNEED：内核将会在合适的时机去释放内存，但进程的 RSS（常驻内存）将会立即减少。如果再次申请内存，内核会重新分配一块新的空间。
• MADV_FREE：只能在 linux 内核版本 4.5 以上才能使用，此操作理论上只是打了一个标记位，只有在内核感觉到内存压力的时候才会将这些打标记的内存回收掉，分配给其他进程使用。这个策略下进程的 RSS 不会立即减少。

不同策略的实际差别

• 理论上 MADV_FREE 效率要高一些，通过在页表中做标记的方式，延迟内存的分配和回收，可以提高内存管理的效率，毕竟内存的回收和分配都是会消耗系统性能的；
• 导致的 RSS 指标变化 MADV_DONTNEED 会导致进程 RSS 会有明显的下降；MADV_FREE 会导致进程 RSS 平稳在高峰，不会得到立即释放；

不同 GO 版本的释放策略

• 在 GO1.12 之前，默认均选择的 MADV_DONTNEED 策略进行内存回收；
• 在 GO1.12~GO1.15，官方默认选择 MADV_FREE 策略进行内存回收；
• 在 GO1.16 及之后，又改回了 MADV_DONTNEED 策略进行回收内存。

在 GO1.12~GO1.15 且内核版本 4.5 以上，mem.rss 指标已经无法准确观测服务内存占用；

解决方法

• 不解决，对程序性能有利，但是会降低一些可观测性；
• 以下任一方法可以解决，但会损失一定性能 把 export GODEBUG=madvdontneed=1 写进服务 control.sh 脚本；
• 升级 GO 版本至 1.16 及以上；

参考资料