在go语言中使用delve调试工具诊断协程泄露流程步骤示例

Go  /  管理员 发布于 9个月前   493

使用delve 调试工具, 不用改代码，直接现场诊断Go协程泄露问题。

安装 delve

在开发环境，我们安装个软件当然是易如反掌。

但是要在生产环境，服务器上安装东西，那就说不准有多少艰难险阻了。

delve 一般是通过命令 

go install github.com/go-delve/delve/cmd/dlv@master 

安装。

但是就要求服务器安装了 go 并且能够连接外部网络。

这已经是比较苛刻的要求了。

最低要求就是能够连接服务器，并且能够把 delve 传上去。

否则就不太好办了。

如果是通过镜像部署的应用，我觉得在打镜像时把 delve 添加进去是个不错的主意，体积不大，

还能防不时之需。

连接程序

第二步就是连接程序，开始 debug 了，这个比较简单，两个命令就能解决

ps -aux |grep $name # 查询 pid， $name 替换为程序名字
dlv attach $pid # 连接程序，$pid 替换为上一步查询到的 pid

显示协程信息

在执行 dlv attach 命令后，就会进入 dlv 的交互控制台。

最简单的话，输入 grs 就能显示协程信息，但在协程泄露的情况下，

做一些过滤和分组可以看的更清楚一点，

命令如下：

grs -w user -group goloc

表示只显示用户协程，并按调起协程的位置分组统计。

详细信息可以通过 help grs 命令查看

测试演示

下面我用一个非常经典的协程泄露场景来演示下

func main() {
    for {
        queryAll()
    }
}
func queryAll() int {
    ch := make(chan int)
    for i := 0; i < 3; i++ {
        go func() { ch <- query() }()
    }
    return <-ch
}
func query() int {
    n := rand.Intn(100) + 100
    time.Sleep(time.Duration(n) * time.Millisecond)
    return n
}

这个代码模拟了 只取返回最快的结果，其他结果被遗弃后一直阻塞发送协程的情况。

运行程序一段时间后，用 dlv 执行 

grs -w user -group goloc 

后输出是这样的：

Type 'help' for list of commands.
(dlv) grs -w user -group goloc
<autogenerated>:1 in runtime.newproc
          Goroutine 1 - User: C:/Work/my-project/learn/main.go:19 main.queryAll (0x8dba37) [chan receive]
        Total: 1
C:/Work/my-project/learn/main.go:17 in main.queryAll
          Goroutine 18 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 6 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 7 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 19 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
          Goroutine 51 - User: C:/Work/my-project/learn/main.go:17 main.queryAll.func1 (0x8dba90) [chan send]
        Total: 333
(dlv)

可以看到，queryAll 一共有 333 个协程，并都处于 chan send 状态。

说明发送被阻塞了，有了这个信息，问题就很清晰明白了。

注意事项

dlv debug 时也会使得内存占用变高，如果内存已经过高，那么可能加快引起 OOM。