go内存泄露case

前端之家收集整理的这篇文章主要介绍了go内存泄露case前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

用go写了一个守护进程程序:用于检测redis的存活状态并将结果写到zookeeper中,部署到redis机器上,对于每个redis实例会有一个goroutine每隔固定时间去检测其状态,由主goroutine负责信号处理等,再接收到信号时kill其他的goroutine。程序运行了一段时间发现,有些redis实例的对应zookeeper的信息不更新,通过日志发现对应redis的goroutine挂掉了。阅读源码发现貌似是zk的第三方库抛出一个非预期的异常导致。

为了解决这个问题,对逻辑重构:由主goroutine每隔固定时间,对于每个redis实例启动一个goroutine去进行检测,避免出现非预期异常导致goroutine挂掉,从而状态信息不更新的情况。由于goroutine的创建开销很低,并且golang官方推荐使用大量的goroutine来抗并发,所以这种方式实现也很合理。重构完,上线测试发现存在内存泄露。

(1)观察GC

首先对代码review,因为半年前写的,并且最近都没用golang,所以没有发现bug。接着,就想看下gc相关的信息,也许可能透漏些东西。网上查了golang gc相关,在runtime的doc中描述了,通过设置环境变量GODEBUG='gctrace=1'可以让go的运行时把gc信息打印到stderr。

GODEBUG='gctrace=1' ./sentinel-agent >gc.log &
gc.log的输出如下:
gc781(1): 1+2385+17891+0 us,60 -> 60 MB,21971 (3503906-3481935) objects,13818/14/7369 sweeps,0(0) handoff,0(0) steal,0/0/0 yields
gc782(1): 1+1794+18570+1 us,21929 (3503906-3481977) objects,13854/1/7315 sweeps,0/0/0 yields
gc783(1): 1+1295+20499+0 us,59 -> 59 MB,21772 (3503906-3482134) objects,13854/1/7326 sweeps,0/0/0 yields
gc781:从程序启动开始,第781次gc

(1):参与gc的线程个数

1+2385+17891+0:分别是1)stop-the-world的时间,即暂停所有goroutine;2)清扫标记对象的时间;3)标记垃圾对象的时间;4)等待线程结束的耗时。单位都是us,4者之和就是gc暂停的整体耗时

60 -> 60 MB:gc后,堆上存活对象占用的内存,以及整个堆大小(包括垃圾对象)

21971 (3503906-3481935) objects:gc后,堆上的对象数量,gc前分配的对象以及本次释放的对象

13818/14/7369 sweeps:描述对象清扫阶段。一共有13818个memory span,其中14在后台被清扫,7369在stop-the-world期间被清扫

0(0) handoff,0(0) steal:描述并行标记阶段的负载均衡特性。当前在不同线程间传送操作数和总传送操作数,以及当前steal操作数和总steal操作数

0/0/0 yields:描述并行标记阶段的效率。在等待其他线程的过程中,一共有0次yields操做

经过观察gc的输出,发现当前堆上对象总数不断增多,没有减少的趋势,这说明存在对象的泄露,从而导致内存泄露。

(2)memory profile

根据golang官网profile指南,在代码添加

import _ "net/http/pprof"

func main() {
    go func() {
        http.ListenAndServe("localhost:6060",nil)
    }()
}
可以在运行时对程序进行profile,通过http访问:

go tool pprof http://localhost:6060/debug/pprof/heap

进行memory profile,默认是--inuse_space,显示当前活跃的对象(不包括垃圾对象)占用的空间。使用--alloc_space可以显示所有分配的对象(包括垃圾对象)。不过这两种方式都没有发现异常。

(3)监控goroutine个数

通过runtime.NumGoroutine()可以获取当前的goroutine的个数。通过给程序添加http server获取一些统计信息来了解程序的运行状态,这是Jeff Dean推崇的方法。通过添加下述代码来实时查看goroutine的个数

    // goroutine stats and pprof
    go func() {
        http.HandleFunc("/goroutines",func(w http.ResponseWriter,r *http.Request) {
            num := strconv.FormatInt(int64(runtime.NumGoroutine()),10)
            w.Write([]byte(num))
        });
        http.ListenAndServe("localhost:6060",nil)
        glog.Info("goroutine stats and pprof listen on 6060")
    }()
通过命令:

curl localhost:6060/goroutines

查询当前的goroutine的个数。通过不程序运行期间,不断查看,发现goroutine个数不断增加,没有销毁的迹象。

(4)goroutine泄露

通过上面的观察,发现存在goroutine泄露,即goroutine没有正常退出。由于每轮(每隔10秒执行一次)都会创建多个goroutine,如果不能正常退出,则会存在大量的goroutine。go的gc使用的是mark and sweep,会从全局变量、goroutine的栈为根集合扫描所有的存活对象,如果goroutine不退出,就会泄露大量内存。

在确定是由于goroutine没有正常退出后,重新review代码,发现了泄露的根本原因。在重构前,在信号处理程序中,为了正常结束程序,对于每个goroutine都有一个channel,用于主goroutine等待所有goroutine正常结束后再退出。主goroutine中,信号处理程序用于等待所有goroutine的代码

waiters = make([]chan int,Num)
for _,w := range waiters {
    <- w
}

执行检查逻辑的goroutine在结束后,会调用ag.w <- 1,用于向主goroutine发送消息。

重构后,由于每轮都会创建goroutine,由于用于主goroutine和检查逻辑的goroutine之间的channel的大小是1,所以所有创建的检查goroutine都阻塞在ag.w <- 1上,不能正常退出。最后,把channel逻辑去掉,就不存在goroutine泄露了。

(5)总结

- goroutine的管理很重要,如果goroutine泄露,就会存在内存泄露

- 内嵌http server,用于查看程序运行状态

- 目前,go的gc还比较脆弱,尽量减少对象的创建,能缓存的就缓存。因为对象多了的话,扫描的时间也会加长

猜你在找的Go相关文章