使用版本：2.6.1
集群情况：1台metad，3台graphd,3台storaged
机器情况：每台机器内存32G
遇到问题：
执行一下两条sql：
（1）MATCH p=(v)- [*1…4] -(t) where id(v)==“45710364” and id(t) == “a0561bad21db3ba82eed9cf6a3850ed5” RETURN p;
（2）FIND ALL PATH WITH PROP FROM “45710364” TO “a0561bad21db3ba82eed9cf6a3850ed5” OVER * BIDIRECT UPTO 4 STEPS
其中Match语句正常返回7200+数据，但是执行FIND PATH语句时单机内存溢出阀值，直接返回错误，无法完成查询操作，经过explain发现卡在第一次执行DataCollect时，导致后续无法进行，所以想请问下是否有相关的文档或说明解释下match与find path出现这种差异的底层原因？同时请问下在5跳范围内是否find path的性能确实优于match语句呀？
附带问题：目前刚刚接触nebula数据库，想压测下服务器性能，但是发现目前系统存在这缓存现象，想请问下这块有显示配置可以关闭缓存吗？高跳数据很少，缓存存在导致压测数据一直不准确。
目前业务场景就是需要查询两点之间指定跳数之内是否存在关系，所以之前尝试用的就是以上两个查询sql，如果有更合适的麻烦指导下，谢谢啦！
1、find path 内存溢出卡在 第一次datacollect 感觉不太正常，因为第一次datacollect的时候 只是取了路径的拓扑结构，并没有带属性，这时候的内存占用不会太多， 你是不是执行完一条语句之后 立即又执行了find path了
2、 find path 的执行效率在2.6.1 版本上是好于 match 的，你可以看一下对应的执行计划
缓存 分为两个方面
1、系统缓存，这个是linux系统自带的
2、nebula中 storage的缓存，这个可以通过 etc/nebula-storage.conf 中的–rocksdb_block_cache 控制
3 如果业务场景是 查询两个点之间是否存在关系，可以使用 find shortest path from xxx to yyy over edge 取判断， 不需要全路径
1 个赞
1.请问一下执行完一条语句之后，再次执行find path有什么问题吗？目前是在进行语句压测，所以确实存在一条find path执行完成之后又执行的情况，请问这个是有什么影响吗？但是我间隔一段时间，数据库全部重启，再次执行还是会有这个内存溢出的问题，使用profile查看确实是卡在了第一次datacollect这边，所以感觉很奇怪。
2.嗯嗯，好的，谢谢了哈，我等下关闭掉测试下。目前默认的是4，如果需要调整是需要改成0是吗？
3.使用shortest查询可以查看是否有关系，但是确定有关系后我还是需要查询所有路径的，最后还是需要用到all，所以需求应该是我说错了，还是需要获取到所有的路径。
4.请问下目前match和find path查询逻辑的区别目前有相关文档介绍吗？
这是刚才又重启之后查询了一次的profile分析，麻烦帮忙看下
刚才1中说的执行完了之后在执行目前是执行完成之后在执行，暂时没有存在并行执行的情况。
而且在执行find path的时候发现查询3跳的时候比4跳、5跳查询结果差距不大的时候性能还差的情况，比如查询结果同样都是个位数的时候，3跳反而可能是最慢的，但是match就是逐跳递增的，请问这个情况是正常的吗？还是我们数据的原因
可能会有内存还没释放完，又执行语句，然后到达水位限制的情况， 卡在第一次datacollect 是什么意思， 是执行这个算子的时候内存溢出了吗
find all path 时候可以不使用 with prop 这样只取拓扑结构，不取点和边的属性
match和find path 底层执行计划的区别 目前没有文档介绍
match 是从一个点出发拓展，直到到达用户指定的步数限制，形成路径的
find path 是从起点 和 终点双向拓展 使用的 双向BFS算法
由于find path 使用的 是双向BFS 算法， 所以3跳和4跳 拓展的次数是一样的 都是2次，性能上区别不会太大， 但是3跳是比5跳要快的， 可能你的数据不是太多，并且由于其他硬件影响，可能会出现3跳快于5跳的情况， 你可以数据量加大一些，就可以看出区别了
因为每次执行的时候会在中间过程内存暴增，然后触发阈值就结束的情况，所以我通过执行profile指令，就是上面的图片，在第一次datacollect的时候发现没有了返回耗时和结果，所以我猜测应该是第一次datacollect的时候内存溢出了，这边可以麻烦帮忙看下那张图片吗？
这是目前的整体数据量，大概都在1-2亿左右，所以还是因为数据量导致的查询偏差是吗？
productALLpath 产生了61行数据，这个不多啊，你总的数据量是多少，你水位限制值是0.8吗
所有的数据量都在上面的图中，你可以看下，大概就1-2亿数据量，水位限制值调整到了0.92了，但是还是报错，我看了下，虚拟机的内存大概在24G左右，当超出阈值的时候，提醒我还需要接近20G，也就是大概整体需要40G左右的内存。
这个跟你查询时候 能够访问到的点和边的数据有关，你可以看一下你用例中的点 2跳和3跳的出边是多少
开始是压测（20）的时候发现出现这个问题，后来是单线程查询了，但是单graph计算的时候还是内存爆了，但是用match大概3s左右是可以出结果的。
查询出边语句：GO 2 TO 2 STEPS FROM “29411389” over * BIDIRECT YiELD src(edge),dst(edge)
A点：
2跳：18条数据
3跳：413条数据
B点：
2跳：38731条数据
3跳：42816条数据
数据量都是用上面的查询语句返回数据量表示的。
单条语句执行 find path 也内存满了，执行不出结果吗
是的，三台机器全部重启，然后单线程执行最上面的find path还是会内存溢出，match大概3.2s出7200+数据。执行第一个datacollect的时候没有返回结果，所以应该就是卡在了这一步了。
好的， 我会排查一下 find path 的内存占用，有进展 在通知你
1 个赞
