Star

关于 FIND SHORTEST PATH的问题

目前不支持指定方向寻找 的 意思是只能按照图中边实际的方向寻找 还是 忽略边的方向性 找到最短路径?


在这张图中,数据结构是 sample->ip,sample->domain,sample-url 无法得到两个同类型结点的最短路径

我理解是可以指定边的类型的,你可以看下文档:https://docs.nebula-graph.com.cn/manual-CN/2.query-language/4.statement-syntax/4.graph-algorithms/find-path-syntax/

我明白能指定类型,但是方向性的问题我目前根据我上面的数据样例和数据规范,如果查找两个同类型结点,最后得到的是空集。也就是说只能根据图中边的方向性来遍历,而且不支持反向或者双向。
如果要用GO FROM 的BiDirect ,得指定两个点之间的跳数或者跳数范围。
不知道目前还有没有别的方法可以对于我这样例里面的两个同类型结点找到最短路径

我目前在一台测试服务器上测试nebula的性能,大概有3百万结点和5百万边,数据的schema就是上面那样的。结点只有一个prop,string。
我如果用GO FROM 的话,比如下面这个:

GO 5 STEPS FROM 576 OVER related_ip BIDIRECT | LIMIT 3;
E0918 00:38:21.768056 23409 GraphClient.cpp:85] Thrift rpc call failed: Channel got EOF. Check for server hitting connection limit, server connection idle timeout, and server crashes.
[ERROR (-3)]:

我的配置也使用了直接截断和蓄水池采样,但最后graphd还是挂了

可以贴一下graphd的log么

内存多大?
看下dmesg是不是OOM了

ERROR LOG:
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
E0918 00:36:18.363291 23221 MetaClient.cpp:513] Send request to [127.0.0.1:45500], exceed retry limit
E0918 00:36:18.392812 23204 MetaClient.cpp:59] Heartbeat failed, status:RPC failure in MetaClient: N6apache6thrift9transport19TTransportExceptionE: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused
E0918 00:36:41.460099 23366 ExecutionPlan.cpp:76] Execute failed: Get neighbors failed

我看了一下dmesg应该是OOM了

内存16g,确实OOM了。这个量级的数据+5层的跳数就吃这么大的内存吗?

另:FIND SHORTEST PATH 的问题还是没太能理解,文档里的关于FIND PATH的描述“不支持指定方向搜索”,在我用起来的实际感觉就是只能按照图中边的方向搜索

可能是storaged和graphd都占用了那么多吧。
没有请求的时候,你机器内存估计就没剩下多少

也不是啊,我这里还剩8g多是free的……
那我在集群上测一下好了

看下进程的内存消耗历史吧,1kw量*属性大概有多少

我这里数据的属性就是ip,domain,url的实际内容和sample的哈希值,边属性是一个int 时间戳。整体数据很简单,本地的csv数据 一共就360m

我把测试机上其他的一些没用的进程都关了。top看的话,不执行5跳查询,free的内存可以到13G。但执行后graphd直接就把内存吃光了

我刚刚统计了一下用于测试起始点周围的一些统计特征,1跳内的related_ip有5个,两跳就有5万个,3跳就15万了。我们也配置了截断和蓄水池

最难受的是graphd会崩掉,目前有什么方法可以让graphd不崩溃吗?可以返回一个结果告知内存不够

15万个点就OOM了?完全没道理啊。

bad_alloc然后OOM是默认行为了,你可以上个watchdog管一下。

这次我有在集群上测试了一下,两个机器配置都是

156G 24核 Intel® Xeon® CPU E5-2650 v4 @ 2.20GHz 4T

执行四跳的遍历没有问题,11秒就出来了。

但是五跳的遍历还是不行,到内存的85%也没有结果,我就终止了。集群中的另一台机器完全没有被利用

终止后停止所有服务,但graphd停不下来,只能kill -9

graphd是单点处理一个请求

我目前的这个结点数量就已经不能支持遍历5跳的结点了吗?我刚刚看其他的帖子,GO N STEPS FROM VID OVER EDGE_TYPE; 实际会返回1,2,……N跳所有的结果?如果我有4跳内的结果,是不是改成 GO 4,5 STEPS FROM 就可以只要5跳的结果?

不过我之前也试过这个,好像也不行。不知道我的理解有没有偏差

不行。
那还不如4跳结果返回给客户端,然后客户端再go 1 step 一次就行了。这样内存会少很多。

浙ICP备20010487号