Match语句执行四跳，内存过大导致graphd重启

问答 问题
1

nebula 版本：v.3.1.0
部署方式：分布式
安装方式：K8S (meta3, graph3, storage*3)
是否为线上版本：Y
硬件信息
磁盘 800G SSD
CPU 、内存信息 64cores128G
问题描述： 环境配置成功后，通过执行Match语句进行四跳查询，观察到graph节点内存激增到85G左右，随后内存不足导致服务重启，查询无法完成；请问1）是否是正常现象？2）是否有手段优化？

语句如下
MATCH (p:Person) -[:knows * 4]->(f:Person) WHERE p.Person.firstName == 'Lysette' return DISTINCT id(f), f.Person.firstName

firstName对应的索引已经建立，并且rebuild成功

2

您这个查询只关心终点，不关心路径，可以用 LOOKUP（从FirstName 查起点） | （管道）GO （查四跳）实现，占用资源小哈。

3

是的，我有用过GO查询 go 4 step from ‘p-8796093460686’ over knows yield knows._dst, $$.Person.firstName，资源占用都还正常，响应时间在40s左右；是不是可以这样理解，Match的话会把路径都拉到内存里？

4

MATCH 的每一跳都会获取点，再把点的所有属性加载（我们有剪枝的优化，在一点点做，每一个版本都会在一些场景下更优），GO 的话只会按照边往下扩展，到终点才按需取点的属性哈。

你可以 lookup on Person where Person.firstName == “Lysette” yield id(vertex) as id | GO FROM $-.id 这样的哈。

不过 GO 和 MATCH 的遍历是有区别的（在重复路径的考虑上）

1 个赞
5

我分别测试了三种场景

  1. lookup
  2. go
  3. lookup on Person where Person.firstName == “Lysette” yield id(vertex) as id | GO FROM $-.id

发现一个现象是第三个语句，比前两个语句单独测试的时延相加，高一个数量级，这个是正常的吗？还是说可以继续优化？

6

可能还是看具体的查询和数据情况？可以 profile 看看，比如我这里没有查数量级。

(root@nebula) [basketballplayer]> GO FROM "player100" OVER follow YIELD id($$)
+-------------+
| id($$)      |
+-------------+
| "player101" |
| "player125" |
+-------------+
Got 2 rows (time spent 2106/9129 us)

Tue, 16 Aug 2022 15:38:35 CST

(root@nebula) [basketballplayer]> LOOKUP ON follow YIELD dst(edge) AS v | YIELD count(*)
+----------+
| count(*) |
+----------+
| 81       |
+----------+
Got 1 rows (time spent 3117/11225 us)

Tue, 16 Aug 2022 15:39:03 CST

(root@nebula) [basketballplayer]> LOOKUP ON follow YIELD dst(edge) AS v | GO FROM $-.v OVER follow YIELD id($$) | YIELD count(*)
+----------+
| count(*) |
+----------+
| 158      |
+----------+
Got 1 rows (time spent 5658/33762 us)

Tue, 16 Aug 2022 15:39:10 CST
7

多谢回复，还是数据集的关系，LOOKUP查出来的结果较多的情况，后面对应的go语句就是高并发，所以有数量级差异

1 个赞
8

昨晚跑了一个大批量的测试，发现有个点在查询时找不到了，因为想压性能，所以日志级别较高，没有输出有价值的信息，重启服务之后，点就回来了，并没有真正丢失，想问一下时因为缓存的问题吗？或是其他什么原因？下面是查询记录，之后不管是一跳还是单纯的lookup都找不到那个点了

1660660928,"lookup on Person where Person.firstName == ""Lysette"" yield id(vertex) as id | GO 4 step FROM $-.id over knows yield distinct knows._dst, $$.Person.firstName",38389476,38626843,true,246166,
1660660966,"lookup on Person where Person.firstName == ""Lysette"" yield id(vertex) as id | GO 4 step FROM $-.id over knows yield distinct knows._dst, $$.Person.firstName",36470039,36832159,true,246166,
1660661004,"lookup on Person where Person.firstName == ""Lysette"" yield id(vertex) as id | GO 4 step FROM $-.id over knows yield distinct knows._dst, $$.Person.firstName",2490,3218,true,0,
1660661004,"lookup on Person where Person.firstName == ""Lysette"" yield id(vertex) as id | GO 4 step FROM $-.id over knows yield distinct knows._dst, $$.Person.firstName",3860,4527,true,0,
9

请问重启的是 GraphD 还是所有的进程哈？

10

重启了graphd和storaged

11

@SuperYoko 请问重启前后查询存在有差异，有可能在某一个 shard 上数据不一样么？

12

go 语句查询速度特别慢是怎么回事啊？

13

不应当，不太确定是不是storage cache存在问题，是否开启了这个呢。

1 个赞
14

重启后查询的语句是一致的，返回的结果也和重启前正确情况一致