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:  拉起进程对应的命令

golang 内存和cpu优化