- 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能改吗？
我也没试过。。。