集群间歇性查询RPC failure, probably timeout

问答 问题
, , ,
1

社区上有着类似的问题，但是看样子木有最终结论

  • nebula 版本：3.4.0
  • 部署方式：分布式
  • 安装方式：RPM nebula-graph-3.4.0.el7.x86_64
  • 是否上生产环境：Y
  • 硬件信息
    • 磁盘（ 推荐使用 SSD）ssd
    • CPU、内存信息 64c 512G

具体问题
1、集群在启动之后，查询一切正常，过一会儿后（大概大概一小时左右），集群查询就会出一下错误，重启后查询回复，以此往复。
Storage Error: RPC failure, probably timeout.

Traverse failed, error E_RPC_FAILURE, part 7
Traverse failed, error E_RPC_FAILURE, part 22
Traverse failed, error E_RPC_FAILURE, part 10
Traverse failed, error E_RPC_FAILURE, part 28
Storage Error: RPC failure, probably timeout., query: match p = (v) return p limit 1;
Request to "1.1.1.1":9779 failed: AsyncSocketException: recv() failed (peer=1.1.1.1:9779, local=2.2.2.2:36474), type = Internal error, errno = 104 (Connection reset by peer): Connection reset by peer
There some RPC errors: RPC failure in StorageClient: AsyncSocketException: recv() failed (peer=1.1.1.1:9779, local=2.2.2.2:36474), type = Internal error, errno = 104 (Connection reset by peer): Connection reset by peer
2

match p = (v) return p limit 1;
你这个查询是想做什么？这种查询对 storage 开销比较大（社区版 limit 没有下推）

3

我们需求需要查询的语句就是类似这种查询path，然后最后有limit，可是服务重启的时候就可以查询，但过一段时间后，查询立马返回Storage Error: RPC failure, probably timeout.且集群资源监控没有任何上涨 :sweat_smile:

4

还有就是我们重启的时候，只需要重启graph服务就可以恢复，现在的怀疑点，是不是graph服务与storage服务通讯的时候，有不可用连接，graph的配置文件里是不是有保持连接或者连接健康检查的配置，能保持连接健康的。

5

Request to “1.1.1.1”:9779 failed: AsyncSocketException: recv() failed (peer=1.1.1.1:9779, local=2.2.2.2:36474), type = Internal error, errno = 104 (Connection reset by peer): Connection reset by peer

你的 IP 是 1.1.1.1 和 2.2.2.2吗？

7

公司ip不能泄漏，就拿这个代替了。
目前貌似解决了，调了graph服务里面调用storage服务的超时时间还有重试参数就好了

1 个赞
8

后续有朋友遇到这个类似问题，可以检查下面俩配置
tcp_keepalive_time
tcp_keepalive_intvl
这是linux内核的配置，如果设置不对就会导致我上述的问题

1 个赞
9

这个设置不对是啥意思？

10

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。