golang系统内存溢出

已于 2024-03-07 13:15:42 修改
阅读量712 收藏 12
点赞数 10
文章标签： golang 开发语言 后端
于 2024-03-07 13:12:09 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/mengdao/article/details/136516819
版权
文章讲述了在Golang服务中遇到内存溢出的问题，通过dmesg和pprof分析确定了服务card_game占用内存过大，随后通过添加内存检查函数和日志追踪，发现是由于参数错误导致的无限递归。文章提供了排查和解决内存泄露问题的步骤和常见原因总结。
摘要由CSDN通过智能技术生成

golang系统内存溢出

发现问题

在一次压测中，服务会在短时间内崩溃，由于时间短，一时不能通过pprof分析问题找出原因

分析问题

dmesg分析

sudo dmesg -H -T |tailn 200
[Wed Mar  6 09:38:26 2024] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[Wed Mar  6 09:38:26 2024] [4185335]  1000 4185335  2527059  1793783 15605760        0             0 card_game
[Wed Mar  6 09:38:26 2024] [4185336]  1000 4185336   313483     1611   212992        0             0 card_gm
[Wed Mar  6 09:38:26 2024] [4187804]     0 4187804     1486       10    49152        0             0 head
[Wed Mar  6 09:38:26 2024] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-237.scope,task=card_game,pid=4185335,uid=1000
[Wed Mar  6 09:38:26 2024] Out of memory: Killed process 4185335 (card_game) total-vm:10108236kB, anon-rss:7175132kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:15240kB oom_score_adj:0

dmesg分析结果显示：服务card_game分配内存已经达到7G多，而机器内存总共才8G，因此内存溢出了

pprof分析

内存达到临界时，主动拒绝服务请求

由于服务崩溃太快，根本抓不到pprof分析报告，想到内存达到临界时，拒绝服务请求，从而有时间抓到pprof报告
在服务请求入口处添加：

func (session *ClientSession) OnReceive(data []byte) {
	defer func() {
		if err := recover(); err != nil {
			logger.ERROR("OnReceive: session panic:%v, %s", err, debug.Stack())
		}
	}()
	// 达到临界时，拒绝服务请求
	if checkMem() == false {
		return
	}
	......
}

func checkMem() bool {
	var mem runtime.MemStats
	runtime.ReadMemStats(&mem)
	total := mem.HeapSys + mem.StackSys + mem.MSpanSys + mem.MCacheSys + mem.BuckHashSys + mem.GCSys + mem.OtherSys
	if mem.Sys >= 6000000000 || mem.Alloc >= 6000000000 || mem.TotalAlloc >= 8000000000 {
		// 打印内存统计信息
		logger.INFO("checkMem: Memory total size=%dbytes, mem.HeapSys=%d, mem.StackSys=%d, mem.MSpanSys=%d, mem.MCacheSys=%d, mem.BuckHashSys=%d, mem.GCSys=%d, mem.OtherSys=%d\n",
			total, mem.HeapSys, mem.StackSys, mem.MSpanSys, mem.MCacheSys, mem.BuckHashSys, mem.GCSys, mem.OtherSys)
		logger.INFO("checkMem: Sys=%d, Alloc=%d, TotalAlloc=%d, NumGC=%d, NumForcedGC=%d", mem.Sys, mem.Alloc, mem.TotalAlloc, mem.NumGC, mem.NumForcedGC) // 已分配的对象大小（字节）
		logger.INFO("checkMem: .........................................\n")
		return false
	}
	return true
}

网上说机器总内存是：total := mem.HeapSys + mem.StackSys + mem.MSpanSys + mem.MCacheSys + mem.BuckHashSys + mem.GCSys + mem.OtherSys	
其实 total  = mem.Sys, 只是系统分配的内存，不是总内存 ，看下文档：
type MemStats struct {
    // 一般统计
    Alloc      uint64 // 已申请且仍在使用的字节数
    TotalAlloc uint64 // 已申请的总字节数（已释放的部分也算在内）
    Sys        uint64 // 从系统中获取的字节数（下面XxxSys之和）
    Lookups    uint64 // 指针查找的次数
    Mallocs    uint64 // 申请内存的次数
    Frees      uint64 // 释放内存的次数
    // 主分配堆统计
    HeapAlloc    uint64 // 已申请且仍在使用的字节数
    HeapSys      uint64 // 从系统中获取的字节数
    HeapIdle     uint64 // 闲置span中的字节数
    HeapInuse    uint64 // 非闲置span中的字节数
    HeapReleased uint64 // 释放到系统的字节数
    HeapObjects  uint64 // 已分配对象的总个数
    // L低层次、大小固定的结构体分配器统计，Inuse为正在使用的字节数，Sys为从系统获取的字节数
    StackInuse  uint64 // 引导程序的堆栈
    StackSys    uint64
    MSpanInuse  uint64 // mspan结构体
    MSpanSys    uint64
    MCacheInuse uint64 // mcache结构体
    MCacheSys   uint64
    BuckHashSys uint64 // profile桶散列表
    GCSys       uint64 // GC元数据
    OtherSys    uint64 // 其他系统申请
    // 垃圾收集器统计
    NextGC       uint64 // 会在HeapAlloc字段到达该值（字节数）时运行下次GC
    LastGC       uint64 // 上次运行的绝对时间（纳秒）
    PauseTotalNs uint64
    PauseNs      [256]uint64 // 近期GC暂停时间的循环缓冲，最近一次在[(NumGC+255)%256]
    NumGC        uint32
    EnableGC     bool
    DebugGC      bool
    // 每次申请的字节数的统计，61是C代码中的尺寸分级数
    BySize [61]struct {
        Size    uint32
        Mallocs uint64
        Frees   uint64
    }
}
MemStats记录内存申请和分配的统计信息，是记录申请和分配信息的。

分析pprof报告

heap报告：
heap统计allocs报告：
allocs统计其中有个模块方法idlePool()突出, 基本断定是这里有异常了

加日志

func (idlemgr *xx) idlePool(idle *IdleData) error {
	if idle.StartTime <= 0 {
		idle.Times += 1
		logger.INFO("idlePool: idle.StartTime:%d <= 0, PlayerId=%d, Times=%d", idle.StartTime, idle.Role.PlayerId, idle.Times)
		...
		 idlemgr.idlePool(idle)
		...
	}
}

再次压测后输出：

2024/03/06 09:37:14.891989 [INFO]idlePool: idle.DurationTime:-875532446 <= 0, PlayerId=1000009, Times=1
2024/03/06 09:37:14.892001 [INFO]idlePool: idle.DurationTime:-875528846 <= 0, PlayerId=1000009, Times=2
2024/03/06 09:37:14.892006 [INFO]idlePool: idle.DurationTime:-875525246 <= 0, PlayerId=1000009, Times=3
......
2024/03/06 09:37:16.504243 [INFO]idlePool: idle.DurationTime:-8846 <= 0, PlayerId=1000009, Times=243202
2024/03/06 09:37:16.504248 [INFO]idlePool: idle.DurationTime:-5246 <= 0, PlayerId=1000009, Times=243203
2024/03/06 09:37:16.504253 [INFO]idlePool: idle.DurationTime:-1646 <= 0, PlayerId=1000009, Times=243204

通过日志分析，有个变量超过int32最大值，数值溢出了，导致无限递归循环
追溯原因，发现客户端有个参数无意中设置为0，而服务端没有验证，因此&^^&

解决问题

服务端调整参数处理

总结

  1. 服务端零信任客户端参数
  2. 在服务中，慎重对待递归处理，不然有时后果非常严重
  3. pprof分析报告显示服务分配内存不大，但系统占用内存非常大，原因可能是方法无限递归了，这部分栈占用算系统的

其他

附其它内存溢出原因

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/ByteDanceTech/article/details/124113705

goroutine 导致内存泄露

  1. goroutine 申请过多
  2. goroutine 阻塞
    • I/O 问题
    • 互斥锁未释放
    • waitgroup 使用不当

select 阻塞

channel 阻塞

  • 写阻塞
    • 无缓冲 channel 的阻塞通常是写操作因为没有读而阻塞
    • 有缓冲的 channel 因为缓冲区满了，写操作阻塞
  • 读阻塞
    • 期待从 channel 读数据，结果没有 goroutine 往进写

定时器使用不当

  1. time.after()使用不当
    默认的 time.After()是会有内存泄漏问题的，因为每次 time.After(duratiuon x)会产生 NewTimer()，在 duration x 到期之前，新创建的 timer 不会被 GC，到期之后才会 GC。
    那么随着时间推移，尤其是 duration x 很大的话，会产生内存泄漏的问题。
  2. time.ticker 未 stop

slice 引起内存泄露

  1. 两个 slice 共享地址，其中一个为全局变量，另一个也无法被 gc；
  2. append slice 后一直使用，未进行清理

排查思路总结

今后遇到 golang 内存泄漏问题可以按照以下几步进行排查解决：

  1. 观察服务器实例，查看内存使用情况，确定内存泄漏问题；

  2. 判断 goroutine 问题；

    • 这里可以使用 1 中提到的监控来观察 goroutine 数量，也可以使用 pprof 进行采样判断
    • 判断 goroutine 数量是否出现了异常增长。

  3. 利用 pprof，通过函数名称定位具体代码行数，可以通过 pprof 的 graph、source 等手段去定位；

    • 排查整个调用链是否出现了上述场景中的问题，如 select 阻塞、channel 阻塞、slice 使用不当等问题，
    • 优先考虑自身代码逻辑问题，其次考虑框架是否存在不合理地方；

  4. 解决对应问题并在测试环境中观察，通过后上线进行观察

mengdao
关注
  • 10
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
Golang分析内存溢出
Zachary的博客
04-08 460
这里是Z哥的个人公众号每周五11：45 按时送达当然了，也会时不时加个餐～我的第「223」篇原创敬上大家好，我是Z哥。最近系统在压测过程中发现有一个程序在压力增大后会内存溢出。正好之前自己对 Golang 里分析 dump 这块还没怎么涉及，借此契机学习一下。网上搜了很多资料，发现 Golang 好像没有手动创建 dump 文件的方式（像 Java 的 jmap，.Net...
为什么Go的自定义error有时候会内存溢出
kevin_tech的博客，微信搜「网管叨bi叨」
10-12 167
分享一个在go tour上看到的练习题，练习里要求用户自己定义一个错误类型，实现 error接口，函数在参数不满足条件的时候返回自定义的错误类型的值。练习中特别提示用户不要在实现的 Er...
Golang处理内存溢出
dkjhl的博客
06-07 1441
golang程序在高并发场景下，主程序异常退出，可能是内存泄露导致，本文主要介绍一些常用工具来定位是否是内存溢出，以及如何使用这些工具
解决golang内存溢出的方法
09-18
主要介绍了解决golang内存溢出的方法，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
golang容易导致内存泄漏的几种情况
weixin_38299404的博客
09-11 3421
golang 内存泄漏
Go-NATS的Golang客户端云本地消息传递系统
08-14
5. **流控制与服务质量(QoS)**：NATS支持流控，可以限制客户端接收消息的速度，防止内存溢出。同时，QoS保证了消息至少被传递一次或者最多传递一次，确保消息的可靠性。 6. **集群支持**：NATS设计为集群模式运行，...
谈谈对Golang IO读写的困惑
09-16
这些函数简化了常见IO任务的执行，例如，ioutil.ReadFile一次性读取整个文件内容，适用于小文件，但如果文件过大，可能会导致内存溢出。因此，对于大文件，通常会结合其他库如bufio进行处理。 3. **os库**： - os...
GoLang1.18.4下载
08-05
5. **安全性强化**：Go 1.18.4可能会加强安全性方面的特性，如加强内存安全，避免缓冲区溢出，或者提高代码审查和审计的便捷性。 6. **编译器优化**：编译器的改进可能包括更快的编译速度、生成更小的二进制文件、...
gbp:Golang最佳做法（GBP）
04-12
同时，避免无限制地创建goroutines，以防内存溢出。 2. **通道（Channels）**： Go语言的通道是一种同步机制，允许goroutines之间安全地传递数据。GBP提倡正确使用带缓冲和无缓冲的通道，根据需求选择阻塞或非阻塞...
Golang 内存分配之逃逸分析
01-07
前言 在C/C++开发中，动态分配内存(new/malloc)需要我们手动释放资源。这样做的好处是，需要申请多少内存空间可以很好的掌握怎么分配。但是这有个缺点，如果忘记释放内存，则会导致内存泄漏。在很多高级语言中(python/Go/java)都加上了垃圾回收机制。 golang 的内存分配之堆和栈 Go的垃圾回收，让堆和栈堆程序员保持透明。真正解放了程序员的双手，让他们可以专注于业务，“高效”地完成代码编写。把那些内存管理的复杂机制交给编译器。 栈 可以简单得理解成一次函数调用内部申请到的内存，它们会随着函数的返回把内存还给系统。下面来看看一个例子： func F() { temp :=
Golang中time.After的使用理解与释放问题
09-20
主要给大家介绍了关于Golang中time.After的使用理解与释放问题，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
整数溢出
火柴人的博客
10-10 226
1，无符整数 在Go语言中有无符整数 32系统无符整数范围是0～4294967295(以下称max) 64系统无符整数范围是0~18446744073709551615(以下称max) max + 1 = 0 max + 2 = 1 max + n = n -1 max * 2 = max - 1 max * 3 = max - 2 max * n = max - n 这有两个题...
Go 内存泄漏排查两例
Salted fish in hand, I have the world.
05-18 637
Go 内存泄漏排查两例例1：Goroutine 泄漏现象排查结论httpclientserver解决thriftserverTips例2：内存居高不下现象排查结论GO 内存释放策略解决方法 例1：Goroutine 泄漏 现象 NumGoroutine 指标持续上涨，且低峰期未下降，判断出现了 Goroutine 泄漏现象。 排查 通过访问线上服务 pprof 暴露出来的 HTTP 接口，拿到当前所有协程的堆栈信息；curl http://「ip:port」/debug/pprof/goroutine
golang变量uint、int大小溢出后的结果
weixin_54433389的博客
01-05 3737
golang中变量的大小溢出会是什么结果呢？ // uint8的取值范围： 0 - 255 var a uint8 = 1 var b uint8 = 255 fmt.Println("减法：", a-b) 这段代码的结果是什么呢？ 很明显uint8的取值范围是0-255之间，此时已经超出范围了，那么超出后的结果是什么呢？0或者0报错？我也不知道，一起来看看最后的结果是怎样？ package main import "fmt" //两个uint类型的数字相减后小于0 func
Lang值转int值的环形溢出问题
HeiDianXiaoWu的博客
08-04 441
数据溢出后会呈现出环形循环的它特性
go语言之append 要注意的问题
初夏的专栏
08-21 5551
package main import (     "fmt" ) func main() {     var s = make([]int, 0, 2)     t := append(s, 1, 3, 4)     fmt.Println(s)     fmt.Println(t) } 这里 用append追加切片，但超出了，原来S的容量（大小为2） 导致
从真实事故出发：golang 内存问题排查指北
字节跳动技术团队官方博客
04-11 4619
动手点关注干货不迷路????问题出现出现报警！！！在日常搬砖的某一天发现了某微服务 bytedance.xiaoming 服务有一些实例内存过高，达到 80%。而这个服务很久没有上线过新版本，所以可以排除新代码上线引入的问题。发现问题后，首先进行了迁移实例，除一台实例留作问题排查外，其余实例进行了迁移，迁移过后新实例内存较低。但发现随着时间推移，迁移过的实例内存也有缓慢增高...
golang的错误处理
公众号
10-20 658
通常在golang中使用错误处理都是这样做的：    err := foo()    if err != nil {        return err    }但是如果该函数需要多次调用，那么每次调用都需要进行错误处理：    var err error    var param1, param2 int    err = foo(param1)    if err != nil {      
golang内存溢出
最新发布
08-30
在Golang中，内存溢出通常发生在程序使用了过多的内存而无法进行正确的垃圾回收。这可能是由于以下几个原因引起的： 1. 无限循环：如果你的程序进入了一个无限循环，没有终止条件，那么它会持续消耗内存直到溢出。...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值