describe space xxx;想问一下这个错误码一般有哪些问题的原因。
另外，图数据库偶尔会出现报错：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登录进去就又能使用，想问一下这几个出现问题的原因是什么？
问题的具体描述：使用客户端来插入数据时，遇到报错提示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的日志。
抱歉我不太会用引用。。。
下面这个问题，确实是使用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
你看下storaged是否有正常启动，可能情况是storaged没有启动或者网络不通。
storaged是正常启动的，网络也是通的，但是好像确实偶尔storaged会挂…这个是什么原因？跟资源要求什么的有关么？？因为我只是试着部署，目前CPU和内存开的都不大，大约只开了60G的内存和2核。。
看下dmesg，有么有啥oom kill
也可以ps 看下进程时间
抱歉不太熟docker+k8s这一套东西…
我进入的容器里面执行的dmesg，好像啥都没有…
使用ps查看进程时间，大约是昨天下午4点左右，刚刚我又出现了报错。。但是storaged还是好好的呃。。
是我哪里弄错了么？
你是怎么部署的，参考哪个文档？
我这么觉得ip都没通呢。
没有噢，IP是通的，有一小段时间数据库是可用的，命令也都是正常的。只是再隔一段时间以后，就会出现我说的那个报错…
自己瞎琢磨的…没看到参考的文档…可用提供一下链接给我么？
而且因为需要固定IP，我需要使用公司提供的某个组件。。好像那个helm就用不了了。。。
而且好像不是间歇性的故障，就一开始是正常的，然后如果从某一刻开始不正常了，就一直都是不正常的，只能退出console然后重新登录这样。。看了storage那个进程也一直活得好好的。。
是不是你的连接idle了一段时间，再次操作就报这个错，是的话吗，是因为连接断开了。
是的！确实是这样！！！这个是正常的么？还是说是我的镜像打得有问题？或者是k8s集群有问题？？？单机部署的时候好像没出现过这种情况呃。。
你设置下 tcp_keepalive_time 相关配置 https://github.com/kubernetes/kubernetes/issues/80298#issuecomment-520766743
请教了专门的负责人，他们说tcp_keepalive_time只是去检查断开的连接，并不会自己去保持链接，取名有问题……似乎好像不是这个的问题？
这是基于k8s部署的文档链接
这是基于docker swarm部署的文档链接
https://docs.nebula-graph.com.cn/manual-CN/3.build-develop-and-administration/2.install/deploy-nebula-with-swarm/
感谢。
问题已查到，是graphd中有一个配置项：–client_idle_timeout_secs，这个默认是0，但是被其他同事修改过了，导致出现了问题。
你好~ 我现在也遇到了这个问题：
我是在 rancher 上面照着 docker-compose.yaml 文件进行配置。
请问一下 –client_idle_timeout_secs 这个配置项是在哪里找到的呀~
这个是 nebula-graph.conf 中的一个 flag，对应的文件位置：
你如果是使用的容器，又没有在外部去覆盖内部的 nebula-graph.conf 配置，只要在 command 中覆盖这个单个的选项就可以了，方式类似：
