golang 内存和cpu优化

背景介绍

在压力测试的过程中程序会发生内存和CPU飙升的情况,并且持续一段时间后,虽有所回落,但是内存还是没有及时回收,分析可能存在内存泄露的情况。

问题分析

(1.)在代码中加入性能分析的监控,具体如下:

import 	(
  _ "net/http/pprof" // 引入 pprof 模块
  _ "github.com/mkevac/debugcharts"  // 可选,图形化插件
)

func main(){
    // ...
    // 内存分析
	go func() {
		http.ListenAndServe("0.0.0.0:8090", nil)
	}()
    // ...
}

(2.) 运行程序,由于程序运行在远端linux服务器,如需在本地查看还需要进行端口映射。当然也可以直接在远端linux服务器上通过命令行方式进行查看,但是追踪代码路径时可能找不到,需要指定代码源路径。

go tool pprof -http 172.0.0.88:8070 http://172.0.0.88:8090/debug/pprof/heap
// 浏览器访问
http://172.0.0.88:8070

(3.)通过jemter进行压力测试

(4.)查看top10的内存占用,分析top10的函数占用,这里可以看到addMap()函数占比较高,可着重分析。

参数说明:

列名 含义
flat 本函数的执行耗时
flat% flat 占 CPU 总时间的比例。
sum% 前面每一行的 flat 占比总和
cum 累计量。指该函数加上该函数调用的函数总耗时
cum% cum 占 CPU 总时间的比例

(5.)停掉jemter的压力测试,等待两分钟后(便于GC进行垃圾回收)查看仍然在占用中的内存。这里可以查询inuse_space和inuse_obj这两个参数。这里也可以通过peek查看具体代码的哪一行占用内存较高。

(6.)既然没有了用户操作,内存还被占用,没有释放,那必然存在问题,进一步查看这一块代码进行分析。

这里分析代码发现,addMap有一个递归操作,在调用该函数结束后,map仍然没有释放,这里需要说明的是go1.14一直存在map内存的问题,go1.17该问题已修复。这里我做了对该函数的性能测试,并打印了内存信息。

// 打印堆栈信息
func printMemStats() {
  var m runtime.MemStats
  runtime.ReadMemStats(&m)
  fmt.Printf("Alloc = %v TotalAlloc = %v  Just Freed = %v Sys = %v NumGC = %v\n",
    m.Alloc/1024, m.TotalAlloc/1024, ((m.TotalAlloc-m.Alloc)-lastTotalFreed)/1024, m.Sys/1024, m.NumGC)

  lastTotalFreed = m.TotalAlloc - m.Alloc
}
-------------------------------------------------------------------
参数说明:
Alloc:当前堆上对象占用的内存大小。
TotalAlloc:堆上总共分配出的内存大小。
Sys:程序从操作系统总共申请的内存大小。
NumGC:垃圾回收运行的次数。
// 基准测试
go test -bench=. -benchmem // 进行时间、内存的基准测试

go test -bench=. -run=none -benchmem -memprofile=mem.pprof
go test -bench=. -run=none -blockprofile=block.pprof
go test -bench=. -run=none -benchmem -memprofile=mem.pprof -cpuprofile=cpu.pprof

测试代码

import (
	"testing"
)

func BenchmarAddMap(b *testing.B) {
	// 运行 addMap 函数 b.N 次
	for n := 0; n < b.N; n++ {
		addMap()
		printMemStats()  // 打印内存信息
	}
}

// 输出内存和CPU的信息
go test -bench=. -run=none \
-benchmem -memprofile=mem.pprof \
-cpuprofile=cpu.pprof \
-blockprofile=block.pprof

// 使用go tool进行分析
go tool pprof cpu.pprof
top10 -cum // 查看top10占用情况
list xxx // 查看具体某个函数的内存

go tool pprof -http=":8080" cpu.pprof  // 使用web界面进行分析

经过对addMap()函数进行性能测试发现,申请的内存一直在增长,总的内存占比也在增长。

(7.)map内存释放

map=nilslice= slice[0:0]

(8.)修改完map后,继续分析,发现goroutine中wg使用也存在部分问题。

WaitGroupAdd(), Done(), Wait()Add(n)nDone()-1wait()
// 错误示例:
func testGoroutine() {
	wg := sync.WaitGroup{}
	for i := 0; i < 10; i++ {
        // wg.Add(1)  // 正确用法
		go func() {
		    wg.Add(1)   // 注意:wg.Add需要放到goroutine外部,才能起到计数的作用
			defer wg.Done()
			fmt.Println("hello world")
		}()
	}
	wg.Wait()
}
sync waitGroupchannel
package gopool

import "sync"

// goroutine pool
type GoroutinePool struct {
	c  chan struct{}
	wg *sync.WaitGroup
}

// 采用有缓冲channel实现,当channel满的时候阻塞
func NewGoroutinePool(maxSize int) *GoroutinePool {
	if maxSize <= 0 {
		panic("max size too small")
	}
	return &GoroutinePool{
		c:  make(chan struct{}, maxSize),
		wg: new(sync.WaitGroup),
	}
}

// add
func (g *GoroutinePool) Add(delta int) {
	g.wg.Add(delta)
	for i := 0; i < delta; i++ {
		g.c <- struct{}{}
	}

}

// done
func (g *GoroutinePool) Done() {
	<-g.c
	g.wg.Done()
}

// wait
func (g *GoroutinePool) Wait() {
	g.wg.Wait()
}

(9.)goroutine修改完后,再次测试效果又好了很多,再分析一下timer和ticker,毕竟这两个也很容易产生内存泄露,进一步完善一下代码。

sendTimer := time.NewTimer(time.Second)
	for {
		if !sendTimer.Stop() {
			select {
			case <-sendTimer.C:
			default:
			}
		}
		select {
		case <-this.exit:
			sendTimer.Stop()
			return
		case <-sendTimer.C:
			// 发送
			// doSomething()
			sendTimer.Reset(time.Second)
		}
	}

(10.)尽可能的少用全局变量,因为全局变量只有在程序结束后,内存才能得到释放。尽量使用局部变量(栈上分配),多个局部变量合并一个大的结构体或数组,减少扫描对象的次数,一次回尽可能多的内存。

(11)defer虽好,但是也要适当使用。

当前代码中有许多地方为了打印日志方便,直接使用defer log.Printf("xxx"),建议直接在函数结尾处打印,或者发生错误的地方打印。defer设计之初,主要用于资源释放,锁的释放等场景。

defer的实现机制:编译器通过 runtime.deferproc “注册” 延迟调用,除目标函数地址外,还会复制相关参数(包括 receiver)。在函数返回前,执行 runtime.deferreturn 提取相关信息执行延迟调用。这其中的代价自然不是普通函数调用一条 CALL 指令所能比拟的。

pidstat -r -p 13084 1
minflt/s: 每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数
majflt/s: 每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生
VSZ:      该进程使用的虚拟内存(以kB为单位)
RSS:      该进程使用的物理内存(以kB为单位)
%MEM:     该进程使用内存的百分比
Command:  拉起进程对应的命令

参考链接