find_path报错

[张学通]

全部组件版本都是3.6版本

FIND ALL PATH WITH PROP FROM "42f3b517265c0fa73e3c7d217399bf4b", "89a3c83fffd2b7c421806a4324e78247", "0298d35d10658f375c380f58568c4e0a" TO "42f3b517265c0fa73e3c7d217399bf4b", "89a3c83fffd2b7c421806a4324e78247", "0298d35d10658f375c380f58568c4e0a" OVER BEE,IPEE,LEL,IHPEEN,BEER,LEE,OPEP,SPE,RED BIDIRECT UPTO 6 STEPS YIELD path as p
2023/11/10 11:59:11 [INFO] Successfully reconnect to host: 127.0.0.1, port: 9669
2023/11/10 11:59:17 Loop error, BigFrames not supported: got size 1112098630

Bye root!
Fri, 10 Nov 2023 11:59:17 CST

panic: Loop error, BigFrames not supported: got size 1112098630

goroutine 1 [running]:
log.Panicf(0x7825c5, 0xe, 0xc0002a3e38, 0x1, 0x1)
        /opt/hostedtoolcache/go/1.16.4/x64/src/log/log.go:361 +0xc5
main.main()
        /home/runner/work/nebula-console/nebula-console/main.go:569 +0x5a8

这个问题猜测是返回的data过大导致的,但是令我疑惑的是5跳的数据并不是很多,速度可以接受,但是到了6跳性能断崖式下跌,查询不出来报了这个错误,这个报错该如何解决呢
另外我更改了operator_thread那个参数,性能上感觉并没有提升太多,而且内存的使用率远上涨了5g左右,cpu在查询的时候并没有明显提升,这个参数是针对一个session创建的查询语句起到优化作用嘛

[wey]

导入计算库算一下 degree，看看是不是有超级节点，感觉可以处理一下。

比如文档中提及的 max_edge_returned_per_vertex

[张学通]

大佬您好,不好意思现在才回复,其实配置文件里面暴力截断是已经做过改成200了,如果再缩减的话可能会影响到其余查询的需求

[wey]

是 prop 特别多，还是数据本身的连接性高哈，去掉 WITH PROP 能接受么？

[Reid00]

可以尝试把FROM TO 后面的点换成一对一，分成多个query 试试能不能行？

[张学通]

嗯嗯,现在的做法是通过这样实现的,因为经过测试发现a,b,c to a,b, c不比做成一条条查询语句union all的性能高(怀疑可能是在计算过程中a-c,c-a这种无意义查询影响了效率),目前来说暂时没有复现出稠密点的报错情况,但就速度来讲,a到c的find_path在6跳以后速度会很慢很慢(5000点边查一分钟是常有的事),即使改了num_operator_threads,调整了缓存大小似乎并没有对单条的查询性能产生影响(似乎缓存并未对他起到作用),这是我目前比较困惑的地方,请问大佬有什么参考建议吗

[张学通]

因为需求上需要保留prop进行处理并且返回哈,所以并不能去掉prop,目前的解决方案是给拆分成多条查询语句union all进行处理的,因为测试的时候发现这样查会导致冗余的数据a-c,c-a这样重复的路径会影响呢,但是目前find_path还有另一个问题,他的查询性能实在很慢,单条查询语句5000个点边要查询1分钟时间,这块不知道有啥优化的建议嘛(即使改了配置里面thread的线程数量,目前来看cpu利用率似乎并没有呢,大概才3%,cpu是20核40线程的)

[Reid00]

六跳以上的查询比较慢，大概率是因为数据量太多，计算耗时，因为六跳以后数据可能翻了很多倍。
调整缓存作用不明显因为可能数据量太大缓存会被刷掉。
当前这个瓶颈应该在路径查找的算子上，当前对于深度较深的情况性能不太友好。
还有个方法，如果大部分数据你能查出来，少量查不出来，可以让这少量的数据用graphx 离线查到数据 做T+1 放到redis 里面。

[张学通]

感谢解惑!对于您说的方法我回去研究一下看看是否可以实现,不过对于缓存的话,我觉得应该不是数据过大导致被刷掉了,目前来看给的缓存空间足够大,并没有填满呢,一个节点大概就50b-100b,find_path在查询的时候查了一下rocksdb里面的log,其实上涨并不是很明显,内存的话倒是明显的涨了,但还不至于到达服务器瓶颈

[MuYi]

你保留prop的目的是做啥呢？是可视化吗？
如果是可视化的话，可以考虑先把点边查出来，然后在用户点击具体点和边的时候，再去查具体属性