背景：
有两个space，a和b
a是在线服务，持续使用中(不停的在进行insert、go等操作)
b是新建的space，打算往里灌数(大量的边，上百亿)
操作步骤：
1.为了往b里面灌数的速度快一些，所以先停掉了auto compact
2.开始往b里面大量灌数
3.灌完数之后忘了打开auto compact了
4.过了很久很久之后想起来了，此时打开auto compact
5.整个集群进入到"假死"状态(所有insert、go请求全部超时，甚至studio都链接不上graph，即便链接上了到选space那里都选不了，疯狂转菊花)
疑问：
1.为什么会造成"假死"状态？还会有什么操作会导致类似的情况发生吗？我应该如何避免？~
2.在已经忘了很久才重新打开auto compact的情况下，我应该如何操作才能顺利的重新开启auto compact？
还望不吝赐教~~非常感谢~！
问题1，一般是没做compact，数据量太大
问题2，可以修改disable_auto_comactions参数（在storage 配置文件里面），设置成false，然后重启服务。
数据量大~ 就应该假死嘛？ compact的线程数是固定的呀~
等到compact结束呢？状态是否恢复正常了？
在compact后恢复正常了~
我那个compact的线程数就4个… 所以即便数据量很大的情况下，compact会导致服务完全不可用吗？~
还有一个后遗症… 就是leader的分布全部混乱了… 然后此时如果你去balance leader的话 他半天没有响应，过一段时间就超时了… 但是你再show hosts的时候,他实际接受了balance leader指令，也执行了balance…
因为我们的part是在一个rocksEngine中的逻辑划分，做compact的时候是针对整个engine的操作，这个过程中会导致partLeader错乱的情况。
compaction的时候，io往往会打满，这种情况下你可以给compaction限速。rate_limit
同时compaction线程数也是可以设置的，num_compaction_threads。
导完数据之后做compaction，建议在线上流量低峰期做。
我猜是1. L0的数量太多了，我记得L0是无法并发的（因为overlap太多了）
or 2. IO太猛了
3. 大数据量写入可以试试已经开发好的spark sst ingest工具。比IO写入更合理一些
感谢各位的解答~！
现在balance leader又出问题了…我再单开一贴…
如果IO很大的时候，raft选举会有问题。。。日志没法写下去。
你storaged的参数贴一下。
配置之前贴过啦~
现在经过一宿了。。io应该已经降下来了~
开了个新帖子~ 大佬请移步