记一次线上Go服务内存占用异常问题排查

背景

最近线上有个服务内存异常增长, 默认服务启动实存应该是25M左右, 但是这个服务运行了一段时间实存达到了32G的量级, 并且还在缓慢增长, QA重启之后内存就恢复到了初始水准, 需要我们定位一下内存异常的问题进行解决
在这里插入图片描述

过程

整吧那就, pprof整起来, 在main 函数增加三行代码

import _ "net/http/pprof"

func main() {
	go func() {
		_ = http.ListenAndServe("0.0.0.0:6060", nil)
	}()
}

点进源码就看见它会注册5个接口, 用来查看维度数据
在这里插入图片描述

代码部署上去之后用top命令可以看到服务占用实存确实是在缓慢增加, 想单看这个服务的top可以用 top -p pid 指定进程id查看
在这里插入图片描述

里面 VIRT 是虚存, 即程序申请的内存; RES就是实存了, 即当前程序已经占用的内存

等服务跑一会就可以进网址http://127.0.0.1:6060/debug/pprof上查看服务占用情况了
在这里插入图片描述

也可以在命令行里面进行交互, 因为要查内存问题, 所以就直接看堆占用

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

用top命令可以查看占用前十的函数

(pprof) top
Showing nodes accounting for 4109.08kB, 100% of 4109.08kB total
Showing top 10 nodes out of 91
      flat  flat%   sum%        cum   cum%
    1028kB 25.02% 25.02%     1028kB 25.02%  bufio.NewReaderSize (inline)
  518.02kB 12.61% 37.62%   518.02kB 12.61%  go.uber.org/zap/buffer.(*Buffer).AppendByte
  514.38kB 12.52% 50.14%   514.38kB 12.52%  encoding/json.typeFields
  512.44kB 12.47% 62.61%   512.44kB 12.47%  encoding/pem.Decode
  512.19kB 12.46% 75.08%   512.19kB 12.46%  runtime.malg
  512.05kB 12.46% 87.54%   512.05kB 12.46%  regexp.newOnePassMachine
  512.01kB 12.46%   100%   512.01kB 12.46%  github.com/jinzhu/gorm.(*Scope).getModelStruct
         0     0%   100%     1028kB 25.02%  bufio.NewReader
         0     0%   100%   512.44kB 12.47%  crypto/tls.(*Conn).Handshake
         0     0%   100%   512.44kB 12.47%  crypto/tls.(*Conn).clientHandshake

可以看到还都比较正常, 没有异常占用的函数; 这样的话就再看一眼网页版的堆占用情况
http://127.0.0.1:6060/debug/pprof/heap?debug=1

在这里插入图片描述

可以看到有很多关于 GetTransactionLevelList 这个方法的占用, 在项目里找到这个方法就很容易就定位到了一行异常代码

context.Set(_r, "key", val)

查看一下源代码
在这里插入图片描述

发现这是 gorilla 里面对当前请求存储特定键值的一个包, 关键是代码调用只有插入(Set)没有删除(Clear), 导致底层 data 和datat 一直在储存所有请求的数据及时间戳;
在这里插入图片描述

这就是这个服务内存异常的原因, 坑的是发现竟然连Get方法都没有调用, 相当于只存不用…emmm由于这块代码是已经离职的同事写的, 检查没用就直接干掉了, 顺便把所有的服务都自查了一下, 相对应的方法都清理了一遍;

改完代码重新部署服务, 果然内存稳定在了初始水准, 问题解决;

结束

这次问题解决是比较顺利的, pprof还有很多好用的可视化界面(需要安装 graphviz) 以及火焰图(需要安装原生pprof工具)供调用分析, 有兴趣的可以看下面两篇博客去实验玩一玩

参考链接

https://blog.csdn.net/wangdenghui2005/article/details/99119941
https://www.jianshu.com/p/4e4ff6be6af9

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
在一个流量高峰期间,我们的网站开始出现了性能问题,特别是Tomcat的worker线程居高不下。这个问题对我们的系统稳定性和用户体验产生了严重影响,因此我们立即进行了排查和解决。 首先,我们使用工具监控了Tomcat的worker线程数,发现在高峰期间线程数增长过快,并且没有下降的趋势。接下来,我们对服务器进行了资源监控,发现CPU和内存的使用率都没有超过正常范围。这表明问题不是由于服务器资源不足导致的。 然后,我们查看了Tomcat的日志文件,发现一些异常错误信息与数据库连接相关。我们怀疑是数据库连接池的问题,因此我们进一步检查了数据库的连接数和连接池的配置。经过对比分析,我们发现数据库连接池的最大连接数被设置得过小,导致在高流量时无法满足请求的需求。我们立即调整了连接池的配置,增加了最大连接数,以应对高峰期的负载。 随后,我们重启了Tomcat,并观察了一段时间。我们发现线程数在高峰期开始时仍然有所增长,但是随着时间的推移开始逐渐下降,最终稳定在一个正常的范围内。这表明我们的排查和解决措施是有效的。 为了进一步确保问题的解决,我们还增加了日志监控和报警机制,以便更及时地发现和解决类似问题。 通过这次经历,我们学到了对于高并发流量情况下的线上问题,需要全面考虑不同组件的性能和配置,并对各个环节进行监控和调整。同时,日志分析和排查是至关重要的工作,能够帮助我们准确定位问题并采取合适的解决措施,最终提升系统的稳定性和性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小僵尸打字员

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值