Star

客户端执行报错ErrorCode: -8。

用户问答 使用问题
#1
  • nebula 版本：基于Nebula v1.0版修改。
  • 部署方式（分布式 / 单机 / Docker / DBaaS）：Docker镜像，K8s部署。
  • 硬件信息
    • 磁盘（SSD / HDD）：SSD
    • CPU、内存信息：
  • 出问题的 Space 的创建方式：执行 describe space xxx;
  • 问题的具体描述：使用客户端来插入数据时，遇到报错提示ErrorCode:-8

想问一下这个错误码一般有哪些问题的原因。

另外，图数据库偶尔会出现报错：Thrift rpc call failed: Channel got EOF. Check for server hitting connection limit, server connection idle timeout, and server crashes.[ERROR (-3)]，以及Thrift rpc call failed: Channel is !good() [ERROR (-3)]，但是重新使用console登录进去就又能使用，想问一下这几个出现问题的原因是什么？

#2

问题的具体描述：使用客户端来插入数据时，遇到报错提示ErrorCode:-8

你可以把返回结果里面的error_msg打印出来，看具体是什么原因，-8错误码的原因有很多。

Thrift rpc call failed: Channel got EOF. Check for server hitting connection limit, server connection idle timeout, and server crashes.[ERROR (-3)]

这个错误是用 console 的时候，console打印的吧，这个应该是服务挂了，你用k8s部署的，再次执行成功，应该是重拉服务了。麻烦可以提供下日志吗？graphd的日志。

1赞
#3

抱歉我不太会用引用。。。
下面这个问题，确实是使用console的时候打印的，graphd里面查的日志提示如下：

E1009 14:50:17.644605  1087 ExecutionPlan.cpp:80] Execute failed: RPC failure in StorageClient: N6apache6thrift9transport19TTransportExceptionE: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused
E1009 14:55:11.450582  1101 StorageClient.cpp:311] Request to [xxx.xxx.xxx.xxx:22509] failed: N6apache6thrift9transport19TTransportExceptionE: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused
#4

你看下storaged是否有正常启动，可能情况是storaged没有启动或者网络不通。

#5

storaged是正常启动的，网络也是通的，但是好像确实偶尔storaged会挂…这个是什么原因？跟资源要求什么的有关么？？因为我只是试着部署，目前CPU和内存开的都不大，大约只开了60G的内存和2核。。

#6

看下dmesg，有么有啥oom kill
也可以ps 看下进程时间

1赞
#7

抱歉不太熟docker+k8s这一套东西…
我进入的容器里面执行的dmesg，好像啥都没有…
使用ps查看进程时间，大约是昨天下午4点左右，刚刚我又出现了报错。。但是storaged还是好好的呃。。

是我哪里弄错了么？

#8

你是怎么部署的，参考哪个文档？

#9

我这么觉得ip都没通呢。

#10

没有噢，IP是通的，有一小段时间数据库是可用的，命令也都是正常的。只是再隔一段时间以后，就会出现我说的那个报错…

#11

自己瞎琢磨的…没看到参考的文档…可用提供一下链接给我么？
而且因为需要固定IP，我需要使用公司提供的某个组件。。好像那个helm就用不了了。。。

#12

而且好像不是间歇性的故障，就一开始是正常的，然后如果从某一刻开始不正常了，就一直都是不正常的，只能退出console然后重新登录这样。。看了storage那个进程也一直活得好好的。。

#13

是不是你的连接idle了一段时间，再次操作就报这个错，是的话吗，是因为连接断开了。

#14

是的！确实是这样！！！这个是正常的么？还是说是我的镜像打得有问题？或者是k8s集群有问题？？？单机部署的时候好像没出现过这种情况呃。。

#15

你设置下 tcp_keepalive_time 相关配置 https://github.com/kubernetes/kubernetes/issues/80298#issuecomment-520766743

#16

请教了专门的负责人，他们说tcp_keepalive_time只是去检查断开的连接，并不会自己去保持链接，取名有问题……似乎好像不是这个的问题？

#17

这是基于k8s部署的文档链接


这是基于docker swarm部署的文档链接
https://docs.nebula-graph.com.cn/manual-CN/3.build-develop-and-administration/2.install/deploy-nebula-with-swarm/
1赞
#18

感谢。
问题已查到，是graphd中有一个配置项：–client_idle_timeout_secs，这个默认是0，但是被其他同事修改过了，导致出现了问题。

1赞
#19

你好~ 我现在也遇到了这个问题：

image
image1018×148 20 KB

我是在 rancher 上面照着 docker-compose.yaml 文件进行配置。
请问一下 –client_idle_timeout_secs 这个配置项是在哪里找到的呀~

#20

这个是 nebula-graph.conf 中的一个 flag，对应的文件位置：

https://github.com/vesoft-inc/nebula-graph/blob/1dd1de06b18b5427b2a4b714ff38956b57432dc0/conf/nebula-graphd.conf.default#L42

你如果是使用的容器，又没有在外部去覆盖内部的 nebula-graph.conf 配置，只要在 command 中覆盖这个单个的选项就可以了，方式类似：

https://github.com/vesoft-inc/nebula-docker-compose/blob/3d3961be3f78034b805cd53e854790a631b6c91a/docker-compose.yaml#L8-L17

浙ICP备20010487号