- nebula 版本：3.8.0
- 部署方式：单机
- 安装方式：RPM
- 是否上生产环境： N
- 硬件信息
- 磁盘 60G
- CPU:4核 32G内存
- 问题的具体描述
数据包含3000个点,6000条边,执行find all path,graphd直接消耗了30多G内存,并且生成了40G的core文件,然后服务不可用.麻烦帮忙分析下,什么情况下会导致这种情形?下面是查询sql:
FIND ALL PATH WITH PROP FROM “16_1” TO “16_1” OVER MXT16 WHERE MXT16.ZHMC != MXT16.JYDFMC AND MXT16.JYND >=2022 AND MXT16.JYND <= 2024 UPTO 12 STEPS YIELD path AS p | ORDER BY $-.p | LIMIT 0,1000
内存和磁盘使用情况截图:
go 采用的是 walk 路径模式，也就是点和边是允许重复的。在这样的情况下。
假如整个图有 3 个点，A，4 条边，关系为：A->B->C->A。那么，如果要找到 A 到 A 的12 跳内的全路径的话。那应该会包含：
A->B->C->A
A->B->C->A->B->C->A
A->B->C->A->B->C->A->B->C->A->B->C->A
如果是 3000 点和 6000 边的情况下，看稠密情况，有可能路径的量也不小。
所以，在数据量不大的情况下，返回的结果是不一定小的；存储的数据量和查询得到的结果的值的量是不一样的概念。
尤其是你还加了 WITH PROP，有可能包含的数据量更多；
另外，还确认下你的 ID 是 FIX_STRING 多少。FIX_STRING 255 和 FIX STRING 32，内存占用大小也差很多。
谢谢老师解答,我ID使用的是FIX STRING 32,为了减少点之间边的数量,数据都是按年汇总的,之前担心12跳数据过多,都是加了limit分页获取的,最大也是获取5000条数据,麻烦咨询一下,如果真的回路数据过多,怎么防止这种吃光内存的现象发生呢?
话说，你是根据什么来做 order by 的？$-.p?
就是这个执行语句:ORDER BY $-.p,这样写有啥问题么?
你期望结果是按照什么排序？你可以做一些尝试，看现在这个和你期望的是否一致。
正常来说，比如应该是根据 p 的长度来排序。
我加上排序主要是为了分页获取数据,最终目的也是为了在数据量比较大的情况下,防止内存溢出,限制输出前5000条数据.查询可以失败,就是希望不要占用太大内存,导致图库不可用.
如果你根据什么来排无所谓，可以把 order by 去掉，性能应该会有点提升
还有一个，你需要返回所有的属性吗？如果不需要的话，可以把 with prop 去掉，这样内存应该能减少不少。
边其实是资金流水数据,如果不按年汇总,边的数据量就非常大了,所以我只能汇总后再用边上的属性进行计算加工.这个limit对内存溢出有作用么?现在数据量一大就超出了水位线,然后graphd服务就被kill掉了,请问老师,有没有什么方案,至少保证服务不挂掉?
memory tracker 配下
汇总/用边上的属性加工计算，和你用不用 with prop 没关系
我查出路径后,再去计算边是否符合查询条件要求,比如6月到12月的合计金额是否符合筛选条件,所以这里获取了所有属性,再在应用中进行一次计算处理
你说在一个能用中计算处理哪些内容？那些内容单独拿出来就可以吧，不需要 with prop
好的,我精简一下数据结构,谢谢
我的意思是，这里的WITH PROP去掉