nebula graph 内存占用过多

nebula graph 在查询时内存占用过多。

  • nebula 版本:2.0.1
  • 部署方式(分布式 / 单机 / Docker / DBaaS):Docker
  • 机器配置: 31核, 256G内存,2T硬盘(HDD)
    描述:
    类似于下面的sql
match p = (p) - [f:follow*1..7] -> (p2) where id(p2) in ["player100", "player101"] return p

目的是想找出指定终点的1-7层的所有路径。
测试环境(点数量1.3亿,边数量9000万,data目录占用磁盘42G)
原本测试开并发跑,同时每个sql的id数量在20000, 发现某个时间内存占用超过100G(还在持续上涨,因为影响到其他服务,被我关掉了)。后来通过调小并发和id数,仍然有一样的问题。最后通过小批次id统计返回时间,定位到部分id查询时间过长。有个id查询用了80s,返回路径数大概是40万,单个id查询时graph内存占用最高达到18G。
在某个帖子看到说深度遍历会占用更多的内存,什么原因导致的?
为什么会占用这么多内存?有没有什么办法可以限制graph占用的内存大小?

目前您的问题是跟 MATCH 的具体实现有关,MATCH 在向外拓展时会去获取路径中所有点边的属性,所以会导致占用内存和执行效率上的问题,这块已经在做优化,目前方案涉及模块较多有 planner/optimizer 还有 storage 层的一些改动,规划在年底给一个完善的实现。届时除了解决性能内存的问题,match 功能的支持也会有上一个台阶。

在 2.0.1 中的版本里没有支持内存控制,在接下来的版本针对物理机部署会有一个内存水位的设置,当超过内存水位时会尽早结束当前query,返回给用户错误,避免进程 OOM,被系统 kill。但这也是一个临时方案,后面我们也规划了更友好的内存控制方式,这块功能也计划在年底的版本给出。

目前我们希望在这两方面改善用户的体验:提升执行效率和优化内存控制,后续也会在 GitHub 的 issue 中及时跟大家同步完成进度。多谢您的反馈!

3 个赞

该话题在最后一个回复创建后7天后自动关闭。不再允许新的回复。

浙ICP备20010487号