MATCH 执行失败 Storage Error

  • nebula 版本:2.0 rc1
  • 部署方式 分布式:
  • 硬件信息
    • 磁盘:HDD
    • CPU、内存信息、网络:Intel® Xeon® CPU E5-2650 v4,156G,千兆网
  • 问题的具体描述
    图库数据背景:5亿边,4亿点
    任务:查询某SAMPLE点外两跳所有的REPORT点
    语句:MATCH (v:SAMPLE)-[e*2]-(v2:REPORT) where id(v)==2624809084832723053 return v2 limit 5

执行 match 语句后显示 Storage Error:part:3,error code:-3

  • 相关的 meta / storage / graph info 日志信息
  • Storage 没报Error,Graph报了Error
E0311 19:36:53.121951 97927 StorageClientBase.inl:225] Request to [172.16.1.47:44500] failed: N6apache6thrift9transport19TTransportExceptionE: Timed Out
E0311 19:36:53.895073 97927 StorageClientBase.inl:225] Request to [172.16.1.48:44500] failed: N6apache6thrift9transport19TTransportExceptionE: Timed Out
E0311 19:36:54.271297 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 3
E0311 19:36:54.271514 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 1
E0311 19:36:54.271539 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 5
E0311 19:36:54.271557 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 7
E0311 19:36:54.271601 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 9
E0311 19:36:54.271621 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 10
E0311 19:36:54.271679 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 8
E0311 19:36:54.271697 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 6
E0311 19:36:54.271715 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 2
E0311 19:36:54.271733 97821 QueryStorageExecutor.h:32] GetNeighborsExecutor failed, error E_RPC_FAILURE, part 4
E0311 19:36:54.271755 97821 QueryStorageExecutor.h:103] Storage Error: part: 3, error code: -3.
E0311 19:36:54.295277 97825 QueryInstance.cpp:120] Storage Error: part: 3, error code: -3.

Storage.ERROR 里没相关的东西

你这个应该是拿的数据量太大,处理超时了,你可以在graphd的配置文件里面添加storage_client_timeout_ms, storage_client_timeout_ms默认为60秒,你可以增大。

--storage_client_timeout_ms=600 
1 个赞

好的,感谢回复。
请问NG现在可以将这种查询任务变成长耗时任务提交吗?然后限制使用资源,一旦资源耗尽或者规定时间耗尽,查询就返回?如果在规定的条件下,几百秒后返回,则把数据以文件形式存储?

因为现在这种3条以上的子图查询任务或者5跳以上的路径查询任务基本都是百秒级别返回,甚至和帖子这个一样,查询提交几十秒后直接崩溃。跑一些match的查询,4条可能就把内存耗尽了,然后得再把graphd拉起来,很麻烦。
希望能有这种允许限制查询时间和查询资源的长耗时查询任务

感谢您的提问,目前还没有这样的机制,但是你可以设置下max_edge_returned_per_vertex,将一些数据截掉。

这个在目前的rc1是不是没有开放?我在rc1的配置文件中没看到这个参数,1.x是有的

rc1没有,rc1是12月份发布的,这个参数是1月5日进去的,你得换nightly版本。

好的,那我等下GA版吧

请问下 这是在哪里设置啊,graphd配置文件在哪呀

这个是加在storaged的配置文件里面

我是docker配置,用find找到的配置文件,是只读的。请问下,怎么找到可修改的配置文件呀

强制保存就好。

还好几个 :joy: 到底是哪个呢

nebula-storaged.conf

也是三个 :rofl:

你的是集群,所以三个都要改

1 个赞

哦哦哦 好滴 感恩 比较小白 :joy:

添加了也是一样的报错呀。。

在「限制查询时间和查询资源的长耗时查询任务」这块,我们通过以下方式实现哈:

  1. 命令行支持 cancel
  2. 以配置的方式限定 query 执行最长时间

有进一步的开发进展到时候我再来同步下信息

1 个赞

改完需要重启吗,,,貌似没有作用呀

需要重启的,你需要知道你的数据量是多少,假如还是超时,可能是你的数据量太大,你修改的时间还不够。

浙ICP备20010487号