社区上有着类似的问题,但是看样子木有最终结论
- 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
match p = (v) return p limit 1;
你这个查询是想做什么?这种查询对 storage 开销比较大(社区版 limit 没有下推)
我们需求需要查询的语句就是类似这种查询path,然后最后有limit,可是服务重启的时候就可以查询,但过一段时间后,查询立马返回Storage Error: RPC failure, probably timeout.且集群资源监控没有任何上涨 ![:sweat_smile: :sweat_smile:](https://discuss-cdn.nebula-graph.com.cn/images/emoji/apple/sweat_smile.png?v=12)
还有就是我们重启的时候,只需要重启graph服务就可以恢复,现在的怀疑点,是不是graph服务与storage服务通讯的时候,有不可用连接,graph的配置文件里是不是有保持连接或者连接健康检查的配置,能保持连接健康的。
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吗?
公司ip不能泄漏,就拿这个代替了。
目前貌似解决了,调了graph服务里面调用storage服务的超时时间还有重试参数就好了
1 个赞
后续有朋友遇到这个类似问题,可以检查下面俩配置
tcp_keepalive_time
tcp_keepalive_intvl
这是linux内核的配置,如果设置不对就会导致我上述的问题
1 个赞
system
关闭
10
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。