gRPC入门系列之6-添加pprof

程序在运行过程中，总是会遇到一些性能问题，比如cpu使用率莫名奇妙的飙升、内存使用率奇高等，轻者导致接口响应速度变慢，重者导致系统崩溃，无法提供服务。

这时候，我们就需要对程序进行性能分析，找出问题所在。在golang中，我们可以使用pprof进行性能分析。今天，我们继续丰富我们的gRPC服务，为其添加pprof组件。

pprof简介

Go语言的pprof库，可以用于分析Go程序的性能瓶颈，它的主要功能有：

提供可视化的web界面。
cpu使用情况分析。
内存使用情况分析。
阻塞分析。
互斥锁分析。
协程分析。

pprof相关包主要有两个：

runtime/pprof：实时采集程序运行时数据以供分析。
net/http/pprof：在runtime/pprof基础上，提供相关http节课，可以通过相关url来查看性能分析数据。

添加pprof

我们此次使用net/http/pprof库，需要监听http端口，来提供相关性能分析服务。

我们在服务端程序中添加如下代码：

go 复制代码

	go func() {
		err = http.ListenAndServe(":6060", nil)

		if err != nil {
			logger.Fatal("pprof start failed", zap.Error(err))
		}
	}()

上面，我们启用了一个监听6060端口的http服务来采集性能分析数据。

接下来，我们重新编译服务端程序并启动：

bash 复制代码

make consuldemo-build && ./consuldemo/bin/server

然后，我们在浏览器中访问http://localhost:6060/debug/pprof/，可以看到如下界面：

其中：

allocs：所有的历史内存分配情况。
block：阻塞情况。
cmdline：命令行调用信息。
goroutine：协程情况。
heap：当前活跃对象的堆内存分配采集情况。
mutex：互斥锁信息。
profile：cpu使用情况。
threadcreate：新的操作系统线程创建情况。
trace：当前程序的执行trace。

更多信息，可以查看源代码(net/http/pprof/pprof.go)或参考文档。

测试

采集过去20s的cpu使用数据

我们执行如下命令，来采集过去20s的cpu使用数据：

bash 复制代码

go tool pprof -seconds 20 -http=localhost:6061 http://localhost:6060/debug/pprof/profile

在上面的命令中，我们从6060端口采集数据，采集时间为20s，并在本地6061端口启动http服务，用于展示采集到的数据。执行成功后，将自动打开浏览器（http://localhost:6061/ui/）：

我们的gRPC服务处于空闲状态，所以可以看到大部分时间用于findRunnable(查找待运行的写成)。

采集过去20s的堆内存使用情况

我们执行如下命令，来采集过去20s的堆内存使用情况：

bash 复制代码

go tool pprof -seconds 20 -http=localhost:6061 http://localhost:6060/debug/pprof/heap

执行成功后，将自动打开浏览器（http://localhost:6061/ui/）：我们点击SAMPLE-objects，查看对象分配情况：

没有任何数据。这是因为我们的服务处于空闲状态，没有进行任何内存分配。下面，我们在服务端程序中添加如下测试代码：

go 复制代码

func allocDebug() {
	// 分配1MB内存
	_ = make([]byte, 1<<20)
}

func main() {
    // ...
    go func() {
        for {
            allocDebug()
            time.Sleep(time.Second)
        }
    }()
    // ...
}

在上面的代码中，我们每隔一秒，都会新建一个切片，为其分配1M字节的内存我们重新编译并启动服务端程序：

bash 复制代码

make consuldemo-build && ./consuldemo/bin/server

重新执行采集命令：

bash 复制代码

go tool pprof -seconds 20 -http=localhost:6061 http://localhost:6060/debug/pprof/heap

执行成功后，将自动打开浏览器（http://localhost:6061/ui/），我们点击SAMPLES->alloc_objects，查看对象分配情况：可以看到，几乎全部对象都由allocDebug函数分配。

实际工作中,不一定非要采用这种方式来进行性能分析，如果知道具体哪个接口产生了瓶颈，可以直接在本地测试这个接口对应的方法。

参考文档

本文由mdnice多平台发布