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

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成功

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

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

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

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

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

1 个赞

我分别测试了三种场景

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

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

可能还是看具体的查询和数据情况?可以 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

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

1 个赞

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

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

重启了graphd和storaged

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

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

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

1 个赞

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

浙ICP备20010487号