磁盘占用暴增,集群失效

  • nebula 版本:3.8.0
  • 部署方式:5台虚拟机,vm1-vm5,分布式部署 metad x5 ; graphd x5 ;storaged x5
  • 安装方式:tar.gz
  • 是否上生产环境:N
  • 硬件信息
    • 每台机器数据磁盘 100G,应用和数据共享空间
    • 8c、16G
  • 问题的具体描述:
    1.我的数据量不大,且没有剧烈变化,稳定在6万+点,4万+边。
    2.集群一共15个partition,replica为3,正常情况下磁盘空间占用,每台不超过2G
    3.我每天早上6点重新upsert一遍全量点和边数据,并rebuild index。
    4.服务可以稳定运行几天,期间磁盘空间没有明显变化,直到出问题的某一次运行:磁盘空间迅速暴涨,打满vm2、vm3 这2个节点,集群失效。具体表现为,2个被打满磁盘的节点,storaged进程exit。
    5.检查文件内容发现,打满空间的是wal文件,接近100g
    6.此时集群无法对外服务,dashboard studio均登录不上,5个节点 查看nebula.service status all,5个metad显示Running,5个graphd 显示running,vm2 vm3 的storaged exit
    7.我尝试重新启动vm2的storaged服务,无法启动
    8.我在vm2节点,stop all后,尝试手动删除vm2的 wal文件,删除了一个文件夹,大小10g,此时磁盘空余10g,尝试启动,start all 发现metad正常启动,storaged也可以启动显示等待添加到集群,graphd报错Heartbeat failed ,status:Unknown error -3521! Faled to wait for meta service ready synchronously.
    9.我怀疑是vm3的服务有问题导致的,于是我在vm2节点再次启动graphd后,立刻来到vm3节点stop all。这次vm2的graphd也正常启动了
    10.此时,我检查集群已经可以对外服务了,2分钟后我在vm3节点start all,服务全部正常启动
    11.我观察磁盘空间变化,5个节点均不断减少占用,查看日志进行了full compaction,但是每台依然占用几十G空间
    12.经过几个小时,磁盘占用不再下降,再次开始快速升高,这次vm1节点磁盘占用到了100%
    13.我没有重启整体的集群或删除space,又过了一天,集群再次在批量upsert数据时,空间暴涨崩溃了

我想问的是:
我每天的使用方式是相同的,是什么机制导致数据量暴涨?该如何避免或进一步排查定位

下图是1天的磁盘空间变化趋势

index 创建好之后如果没有删除重建可以不用再 rebuild
全量数据 upsert ,如果数据可以直接覆盖式更新,建议该用 insert 性能会更好一些,upsert 我理解是单调数据在需要 where 条件限制是否更新的时候再使用,或者先全量查出来,然后更具实际需求把新数据拼装好在批量 insert 效果也是会比批量 upsert 要好很多的

2 个赞

另外,你数据本身有变更吗?

数据有变更,是IT基础环境相关的数据,例如vm,集群,物理机,软件,网络策略等数据和之间的关系,数据每天都会有变化,总量基本保持不变。

确实,我这个场景全改成insert也可以满足