我有一个 grpc 基准测试代码,它使用一个函数使用 for-select 子句将数百个 goroutine 通道合并到一个通道。代码是这样的 func (b *B) merge( ctx context.Context, nodes ...<-chan *pb.Node, ) chan *pb.Node { allNodes := make(chan *pb.Node) var wg sync.WaitGroup wg.Add(len(nodes)) for _, n := range nodes { go func(n <-chan *pb.Node) { defer wg.Done() for { select { case <-ctx.Done(): return case val, ok := <-n: if ok { allNodes <- val } } } }(n) } go func() { wg.Wait() close(allNodes) }() return allNodes}当我在ubuntu 16.04中通过top命令监控代码时,我看到2核服务器疯狂旋转,CPU使用率超过196%。然后我使用 pprof 包分析我的代码,它说我的 98% 的 cpu 都在运行这个函数,并且 top 函数生成如下结果 flat flat% sum% cum cum% 1640ms 5.78% 5.78% 27700ms 97.60% B (*B).merge.func1 5560ms 19.59% 25.37% 22130ms 77.98% runtime.selectgo 770ms 2.71% 28.08% 11190ms 39.43% runtime.sellock 2700ms 9.51% 37.60% 10430ms 36.75% runtime.lock 7710ms 27.17% 64.76% 7710ms 27.17% runtime.procyield 460ms 1.62% 66.38% 3850ms 13.57% context.(*cancelCtx).Done 1210ms 4.26% 70.65% 3350ms 11.80% runtime.selunlock 2700ms 9.51% 80.16% 2900ms 10.22% sync.(*Mutex).Lock 2110ms 7.43% 87.60% 2140ms 7.54% runtime.unlock 360ms 1.27% 88.87% 860ms 3.03% runtime.typedmemclr任何人都可以给我一些关于如何编写正确的代码来合并大量通道的建议,似乎这个 for-select 块只会让 cpu 变得疯狂,而在它后面使用 procyield 这不是一个非常有前途的机制?有没有办法控制进程的cpu使用率?
2 回答
阿晨1998
TA贡献2037条经验 获得超6个赞
似乎最有可能的是nodes在取消上下文之前关闭参数中传递的通道。这会将您的for循环变成紧密循环,从而消耗所有可用的 CPU。ok由于通道一旦关闭就无法重新打开,因此一旦为 false,您就可以安全地从 goroutine 返回,这应该可以解决该问题:
go func(n <-chan *pb.Node) {
defer wg.Done()
for {
select {
case <-ctx.Done():
return
case val, ok := <-n:
if !ok {
return
}
allNodes <- val
}
}
}(n)
叮当猫咪
TA贡献1776条经验 获得超12个赞
封闭的 chan 不会阻塞 - 请参阅https://dave.cheney.net/2013/04/30/curious-channels
关闭后将你的 chan 设置为零。
case val, ok := <-n:
if ok {
allNodes <- val
} else {
n = nil
}
然后 select 将阻塞,仅等待完成消息。
- 2 回答
- 0 关注
- 142 浏览
添加回答
举报
0/150
提交
取消