内容简介:我们在发布一个 go 应用时,默认都会启用两个 http handler: 一个是 pprof,方便线上动态追踪问题;另外一个是 prometheus 的 metrics,这样就可以通过 grafana 准实时的监控当前 runtime 信息,及时预警。就像下面这样:最近我在优化一个 push 服务的时候,便观察到了一个 goroutine 泄露问题:
我们在发布一个 go 应用时,默认都会启用两个 http handler: 一个是 pprof,方便线上动态追踪问题;另外一个是 prometheus 的 metrics,这样就可以通过 grafana 准实时的监控当前 runtime 信息,及时预警。就像下面这样:
package router import ( "net/http" _ "net/http/pprof" "github.com/prometheus/client_golang/prometheus/promhttp" ) func InitAdmin() { adminRouter := http.DefaultServeMux adminRouter.Handle("/metrics", promhttp.Handler()) adminServer = &http.Server{ Addr: ":8081", Handler: adminRouter, } go func() { if err := adminServer.ListenAndServe(); err != nil { println("ListenAndServe admin: ", err.Error()) } }() }
最近我在优化一个 push 服务的时候,便观察到了一个 goroutine 泄露问题:
测试的客户端仅仅 30 个左右,基本都不会很活跃,但是却看到 goroutine 在持续上涨。怎么查出那些异常的 goroutine 呢?我所知道的有下面几个方法:
- 给程序发送
SIGQUIT
信号,也就是kill -3 pid
- 程序中监听信号,之后通过
runtime.Stack()
获取所有 goroutine 信息 - 通过 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 的曲线明显趋于平缓:
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Netty堆外内存泄露排查盛宴
- RN 容器的内存泄露排查手记
- Jedis的socket内存泄露问题排查
- [Golang]记一次Goroutine泄露问题的排查
- 震精!Spring Boot内存泄露,排查竟这么难!
- 一次漫长的 Dubbo 网关内存泄露排查经历
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
锦绣蓝图
[美] 沃德科 (Christina Wodtke)、[美] 戈夫拉 (Austin Govella) / 蔡芳 / 人民邮电出版社 / 2009-11-01 / 59.00
Web 2.0和社会化大趋势下,你的网站发展喜人,但是问题也接踵而来:信息变得越来越庞杂无序,业务流程愈加复杂,搜索和导航越来越难,用户对使用体验的要求也越来越高……怎么办? 作者非常通俗易懂地讲述了如何规划易用的网站及其背后的信息架构原理。首先介绍了建立信息架构的八项基本原则,然后重点强调了组织系统和元数据在信息架构中的作用,并指出设计搜索和导航需要考虑的问题和方法,另外还补充了当今热门的......一起来看看 《锦绣蓝图》 这本书的介绍吧!