- 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天的磁盘空间变化趋势
