gRPC 服务器在 SendMsg 上被阻止

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《gRPC 服务器在 SendMsg 上被阻止》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

我们遇到了一个问题，即我们的 grpc 流服务器在 sendmsg 上被阻止，并显示以下堆栈跟踪：

google.golang.org/grpc/internal/transport.(*writequota).get(0xc000de4040, 0x32)
    /root/go/pkg/mod/google.golang.org/[email protected]/internal/transport/flowcontrol.go:59 +0x74
google.golang.org/grpc/internal/transport.(*http2server).write(0xc000bb4680, 0xc000aa6000, {0xc000f2be60, 0x5, 0x5}, {0xc000d6d590, 0x2d, 0x2d}, 0x0)
    /root/go/pkg/mod/google.golang.org/[email protected]/internal/transport/http2_server.go:1090 +0x23b
google.golang.org/grpc.(*serverstream).sendmsg(0xc0002785b0, {0xb8f9e0, 0xc000b686c0})
    /root/go/pkg/mod/google.golang.org/[email protected]/stream.go:1530 +0x1cc

我们的服务器单向流传输到客户端。我们在节点上每 4-6 小时就会遇到此问题，但大约 15 分钟后，tcp 连接将关闭，客户端将重新连接，并且流将像以前一样继续。我们通过每 10 秒保持活动一次来初始化服务器来解决此问题：

server := grpc.newserver(grpc.keepaliveparams(keepalive.serverparameters{时间: time.duration(10) * time.second, 超时: 0}))

过去两天这个问题不再发生。现在，这个问题在过去 5 小时内一直在单个节点上发生，而且还没有消失。

这是 ss 的输出：

$ ss -ntmp|grep -A 1 9222
ESTAB      0      0      10.192.254.1:9222               10.120.224.70:50380
     skmem:(r0,rb524288,t0,tb524288,f0,w0,o0,bl0,d0)

对于在节点上正常运行的服务器，t (wmem_alloc) 值和 w (wmem_queued) 值不为零。根据这个答案，这表明没有数据包排队等待传输。

我还看到服务器每 10 秒发送一次保持活动的 ack。顺序是：

• 服务器发送psh、ack
• 客户端立即响应 psh、ack
• 服务器向上面发送 ack
• 服务器在10秒后再次发送psh、ack

所以服务器保活机制认为一切正常。我没有看到客户端有任何保持活动状态。我会尝试为客户端设置保持活动状态，但为什么会出现此问题？

正确答案

在 (*writequota).get 中遇到卡住的 sendmsg 类似问题 通过使用 mutex 保护 sendmsg 来防止并发调用解决：

对 type clientstream 接口 的评论说：

// ... but it is not safe
// to call SendMsg on the same stream in different goroutines. It is also
// not safe to call CloseSend concurrently with SendMsg.

今天关于《gRPC 服务器在 SendMsg 上被阻止》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！