SUBMIT JOB COMPACT要如何避免磁盘占用100%

  • nebula 版本:2.0rc1
  • 部署方式(分布式 / 单机 / Docker / DBaaS):docker swarm
  • 硬件信息
    • 磁盘( 推荐使用 SSD)ssd
    • CPU、内存信息
      使用中发现,如果关闭自动压缩,磁盘占用超过50%,这个时候手动提交SUBMIT JOB COMPACT,会到导致压缩失败,这种情况如何处理。

自动压缩?你是指 自动compact吧? 如果是自动compact的话,失败能发下失败日志吗?

不是,手动提交SUBMIT JOB COMPACT。我举个例子,我有300G数据,但是我只有200G剩余空间,这个时候磁盘会占用到100%,目前暂时只能使用自动压缩,好像可以避免占用100%。

占用100%是指硬盘空间100%还是IOstat 100%?

磁盘空间。
这里可以设计成一边压缩,一边删除?

这个是lsm tree的大保健的原理。
submit job compact 是全量大保健
disable_auto_compact 是部分小保健。

好吧,那手动提交的时候,得注意一下了

disable_auto_compact 可以设置参数减小每次L0到L1的数据量(临时磁盘占用)吗

大保健就是一把梭哈。一把拉上所有的sst文件一起干
小保健就是一点点来。一把只拉上几个sst文件一点点干。
所以小保健的空间放大问题会好很多,但是,读写放大问题会严重很多。

我预留了20%磁盘空间,现在自动compact也会100%磁盘占用,我想降低(限制)小保健单次的sst文件数,避免小保健也导致磁盘100%。。。,这个有参数可以控制吗
极端情况下,我至少得保留50%的硬盘空间,才能开启compact

这个我也不确定了,得翻翻新版本的rocksdb参数。

wal可以删除掉

我已经把wal的日志删除时间设的很短了,
我想的是disable_auto_compact=false尽量变的可控,我也翻了下rocksdb的参数配置,没有找到所以问下你
如果compact不能限制的话,那结合disable_auto_compact=true使用,将会变的非常不可控
我暂时想到的是把L0,L1的压缩也开启,这个nebula要如何配置

要不,,,咱再买一块硬盘。。。。

rocksdb_compression_per_level=no:no:lz4:lz4::zstd这个nebula能改吗?

我也没试过。。。

浙ICP备20010487号