meta服务内存激增

  • nebula 版本:3.4.0
  • 部署方式:分布式
  • 安装方式:Docker
  • 是否上生产环境:Y
  • 硬件信息
    • 磁盘 2t ssd *5
    • CPU、内存信息 16c/32g * 5
  • 问题的具体描述

我们的使用场景如下:数据统一推送到kafka,然后从kafka消费数据,调用java客户端写入nebula

背景:库中大概总计存储了四千万的点边,点边比例大概1:1, 在前端时间,我们因为业务调整,更换了kafka的consumer的消费组,意味着kafka的数据,我们重新消费了。同时我们正常发送的数据也是会有部分重复的数据。

现象:在更换了消费组后,meta服务的主节点使用内存激增,从1g左右一直升到24g多,然后超过了docker的限制,被强制kill了。再重启还是会出现这个问题,直到kafka积压被消费完。然后meta的内存就使用就恢复正常了

复现:我们尝试在测试环境复现了,发现当nebula中有一定的存量数据之后,写入完成重复的数据,会导致meta的主节点内存增长很快,但是发送不完全重复的数据,meta的主节点内存就比较平稳

我们经过讨论后认为内存增长更有可能是因为把session的信息写到了meta,其中包含的query导致的内存增长。而与数据重复无关。能否结合你们的数据做一次控制变量的交叉实验来排除这种可能

意思是需要以下场景:
复用相同的session,然后只执行写入的语句
新建session,执行写入

可以的来排除session的因素,也可以测一下交换一下重复数据的部分,排除query的因素

好的,我明天先验证下复用session的场景

我还想问一个问题,我是用的是sessionPool的session池执行的语句,同时我这边每个space之间的sessionPool是隔离的,所以不会存在session切换space的场景,那么除了新建session还有什么场景会导致session的信息写到meta呢?

休假了,刚回来。已经验证过了。是因为我们把语句的上报时间改的比较短,然后大量写入导致的

1 个赞

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。