记一次grpcserver内存/吞吐量优化

背景

最近，上线的采集器忽然时有OOM。采集器本质上是一个grpc服务，网络设备通过grpc协议将数据上报后，采集器进行格式等整理后，发往下一个系统（比如分析，存储）。

打开运行环境，发现特性如下：

1. 每个采集器实例，会有数千个设备相连。并且会建立一个双向 grpc stream，用以上报数据。


2. cpu的负载并不高，但内存居高不下。
   
   初步猜想，内存和stream的数量相关，下面来验证一下。

优化内存

这次，很有先见之明的在上线就部署了pprof。这成为了线上debug的关键所在。

import _ "net/http/pprof"
go func() {
logrus.Errorln(http.ListenAndServe(":6060", nil))
}()


先看协程

一般内存问题会和协程泄露有关，所以先抓一下协程：

go tool pprof http://localhost:6060/debug/pprof/goroutine


得到了抓包的文件 /root/pprof/pprof.grpc_proxy.goroutine.001.pb.gz，为了方便看，scp到本机。

在本地执行：

go tool pprof -http=0.0.0.0:8080 ./pprof.grpc_proxy.goroutine.001.pb.gz


如果报错没有graphviz，安装之：

yum install graphviz


此时进入浏览器输入http://127.0.0.1:8080/ui/，会有一个很好看的页面。

在这里，会发现有13W个协程。有点多，但考虑到连接了10000多个设备。

1. 这些协程，有keepalive, 有收发包等协程。都挺正常，其实问题不大。


2. 几乎所有的协程都gopark了。在等待。这也解释了为什么cpu其实不高，因为设备连上了但是不上报数据。占着资源不XX。

再看内存

协程虽然多，但没看出什么有价值的东西。那么再看看内存的占用。这次换个命令：

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


-inuse_space 代表观察使用中的内存

继续得到数据文件，然后scp到本机执行：

go tool pprof -http=0.0.0.0:8080 ./pprof.grpc_proxy.alloc_objects.alloc_space.inuse_objects.inuse_space.003.pb.gz


发现grpc.Serve.func3 ->...-> newBufWriter占用了大量内存。

问题很明显，是buf的配置不太合适。

这里多提一句，grpc服务端内存暴涨一般有这几个原因：

1. 没有设置keepalive，使得连接泄露


2. 服务端处理能力不足，流程阻塞，这个一般是下一跳IO引起。


3. buffer使用了默认配置。ReadBufferSize和WriteBufferSize默认为每个stream配置了32KB的大小。如果连接了很多设备，但其实cpu开销并不大，可以考虑减少这个值。

修改后代码添加grpc.ReadBufferSize(1024*8)/grpc.WriteBufferSize(1024*8)配置

var keepAliveArgs = keepalive.ServerParameters{
Time: 10 * time.Second,
Timeout: 15 * time.Second,
MaxConnectionIdle: 3 * time.Minute,
}
s := grpc.NewServer(
.......
grpc.KeepaliveParams(keepAliveArgs),
grpc.MaxSendMsgSize(1024*1024*8), // 最大消息8M
grpc.MaxRecvMsgSize(1024*1024*8),
grpc.ReadBufferSize(1024*8), // 就是这两个参数
grpc.WriteBufferSize(1024*8),
)
if err := s.Serve(lis); err != nil {
logger.Errorf("failed to serve: %v", err)
return
}


重新发布程序，发现内存占用变成了原来的一半。内存占用大的问题基本解决。

注意：减少buffer代表存取数据的频次会增加。理论上会带来更大的cpu开销。这也符合优化之道在于，CPU占用大就（增加buffer）用内存换，内存占用大就（减少buffer）用cpu换。水多了加面，面多了加水。如果cpu和内存都占用大，那就到了买新机器的时候了。

优化吞吐

在优化内存的时候，顺便看了一眼之前不怎么关注的缓冲队列监控。惊掉下巴。居然有1/4的数据使用到了缓冲队列来发送。这势必大量的使用了低速的磁盘。

这里简单提一下架构。

1. 服务在收到数据之后并处理后，有多个下一跳（ai分析，存储等微服务）等着发送数据。


2. 服务使用roundrobin的方式进行下一跳的选取


3. 当下一跳繁忙的时候，则将数据写入到buffer中，buffer是一个磁盘队列。并且有另一个线程负责消费buffer中的数据。

简单用代码来表示就是：

func SendData(data *Data){
i+=1
targetStream:= streams[i%len(streams)]
select{
case targetStream.c<- data:
//写入成功
case <-time.After(time.Millisecond*50):
bufferStream.c<-data // 超时，写入失败，写到磁盘缓存队列中，等待容错程序处理
}
}


这种比较通用的玩法有几个硬伤

1. 当某个下一跳stream的延时比较高的时候，就会引发大量的阻塞。从而使得大量的数据用到缓存。


2. time.After里的超时时间设成什么，很让人头痛。如果设得太大，虽然减少了缓冲的使用率，但增加了数据的延时。

思考了一下，能不能利用go的机制，从之前的轮循发送，换成哪个stream快就往谁发。

于是，我把代码写成了这样：

// 引入baseCh，所有的数据先发到这
baseCh:= make(chan *Data)
// 为每个下一跳的stream建立一个协程，用来发送数据
for _,stream := range streams{
stream:=stream
go func(){
for data:=range baseCh{
select{
// 在stream实现中使用一个独立的协程管理本stream的发送
case stream.c <- data:
case <-stream.ctx.Done():
// 这个数据为了它不丢失，让它重新进入buffer
buffer.Send(data)
return
}
}
}()
}
func Send(data *Data){
select{
case bashCh<-data:
case <-time.After(time.Millisecond*50):
buffer.Send(data)
}
}


这相当于引入一个baseCh，把Send函数改造成了一进多出的模式。从而不会让一个stream的阻塞频繁的卡住所有数据的发送。让所有的数据发送被归集到baseCh，而不是每次发送都等待超时。

在做这一个改动时，有一点顾虑：

chan本质上是一个有锁队列，频繁的加锁会不会反而影响吞吐？

这里需要指出：

1. 无论是bashCh还是stream.C，都使用的无缓冲channel。理论上，无缓冲channel的性能会优于有缓冲的channel，因为不需要管理内置的队列。这在一些测评中有所体现。


2. 写入channel一定要有超时或者退出机制，也就是：

select{
case bashCh<-data:
case <-time.After(time.Millisecond*50): // 每次写channel都必须防御式的使用超时或退出进制，避免死锁
buffer.Send(data)
}


实践是检验真理的唯一标准，立马上线灰度，发现多虑了。10000个写入端频繁调用Send函数时，系统资源并没有太大的波动。反而磁盘缓冲的使用大大减少了。

分批灰度变更，使得磁盘缓冲现在的使用几乎归零。

当看到监控图后，我激动的哇的一声哭出来，心里比吃了蜜还甜，感到自己的技术又精甚了不少。胸口的红领巾更红了。