踩坑记：go服务内存暴涨

这周换换口味，记录一下去年踩的一个大坑。

== 起 ==

大概是去年8月份，那会儿我们还在用着64GB的“小内存”机器。

由于升级一次版本需要较长的时间（1~2小时），因此我们每天只发一次车，由值班的同学负责，发布所有已merge的commit。

当天负责值班的我正开着车，突然收到 Bytedance-System 的夺命连环call，打开Lark一看：

[ 规则 ]：机器资源报警

[ 报警上下文 ]：

 host: 10.x.x.x

内存使用率: 0.944

[ 报警方式 ]：电话&Lark

打开ganglia一看，更令人害怕：

== 承 ==

这看起来像是典型的内存泄漏case，那就按正常套路排查：

一方面，通知车上的同学review自己的commit，看看是否有代码疑似内存泄漏，或者新增大量内存占用的逻辑；

另一方面，我们的go服务都默认开启了pprof，于是找了一台机器恢复到原版本，用来对比内存占用情况：

$ go tool pprof http://$IP:$PORT/debug/pprof/heap 
(pprof) top 10
Showing top 10 nodes out of 125
      flat  flat%   sum%        cum   cum%
 2925.01MB 17.93% 17.93%  3262.03MB 19.99%  **[此处打码]**
 2384.37MB 14.61% 32.54%  4817.78MB 29.52%  **[此处打码]**
 2142.40MB 13.13% 45.67%  2142.40MB 13.13%  **[此处打码]**
 ...

就这样，一顿操作猛如虎，涨跌全靠特朗普，最终结果是，一方面没看出啥问题，另一方面也没看出啥问题。

正在一筹莫展、准备回滚之际，内存它自己稳了：

虽然占用率仍然很高，但是没有继续上升，也没有出现OOM的情况。

== 转 ==

排查过程中，我们还发现一个现象：并不是所有机器的内存都涨。