Goroutine 泄露排查

原创
2019/06/03 08:18
阅读数 24

我们在发布一个 go 应用时,默认都会启用两个 http handler: 一个是 pprof,方便线上动态追踪问题;另外一个是 prometheus 的 metrics,这样就可以通过 grafana 准实时的监控当前 runtime 信息,及时预警。就像下面这样:

  
  
  1. package router


  2. import (

  3. "net/http"

  4. _ "net/http/pprof"


  5. "github.com/prometheus/client_golang/prometheus/promhttp"

  6. )


  7. func InitAdmin() {

  8. adminRouter := http.DefaultServeMux

  9. adminRouter.Handle("/metrics", promhttp.Handler())


  10. adminServer = &http.Server{

  11. Addr: ":8081",

  12. Handler: adminRouter,

  13. }


  14. go func() {

  15. if err := adminServer.ListenAndServe(); err != nil {

  16. println("ListenAndServe admin: ", err.Error())

  17. }

  18. }()

  19. }

最近我在优化一个 push 服务的时候,便观察到了一个 goroutine 泄露问题:

测试的客户端仅仅 30 个左右,基本都不会很活跃,但是却看到 goroutine 在持续上涨。怎么查出那些异常的 goroutine 呢?我所知道的有下面几个方法:

  1. 给程序发送 SIGQUIT 信号,也就是 kill-3pid

  2. 程序中监听信号,之后通过 runtime.Stack() 获取所有 goroutine 信息

  3. 通过 pprof 获取 /debug/pprof/goroutine

第一种方法会丢失第一现场,并且很难溯源,所以一般在很早期的测试时使用。第二种要提前在程序中埋好点,也是很多开源项目中使用的方法。但是我更喜欢使用第三种方法,pprof 大家一般都是生成 CPU、MEM 火焰图来分析性能问题,殊不知其 HTTP 的接口是分析 goroutine 泄露绝佳的工具。

就拿我的这次案例来说,直接通过 HTTP 地址就可以拿到所有的 goroutine 概况:

可以看到一共有 288 个 goroutine, 但是客户端只有 29 个(一读一写还有一个消息重传),消息重传却有 154 个(理论上也应该是 29 个)。很明显就是 ack 泄露导致的,通过修改请求参数 debug=2,可以看到更多细节:

上面这个图是我修复之后补得,实际上应该能看到 ack 是由于阻塞在 channel 的接收中。经过一番排查,问题最终定位在 reader 和 writer 在退出的时候没有正确关闭 channel 导致。修复后,可以看到 goroutine 的曲线明显趋于平缓:

本文分享自微信公众号 - poslua(poslua)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
在线直播报名
返回顶部
顶部