为了更快地定位、解决问题，麻烦参考下面模版提问 ^ ^
提问参考模版：
数据量不大，40min有点异常。建议插入数据后做一下compact，然后再rebuild index .
还有如下问题：
1.1.1.0 环境如何做compact?
2.正在rebuild的过程如何杀掉？
3.这个能从日志定位一些问题么？
经排查，我们这边有一个storaged节点挂了，我随后拉了起来。
之前这个storaged还是好的，我是在一个9kw级别的点上做了索引并rebuild，然后挂了。
请问这样rebuild索引再tag status上还是running的，如何才能停止之前的rebuild过程.
我在测试的时候rebuild，也出现过storaged挂掉的情况。后来直接把auto_compact打开了，index也提前建好
内存多大的？是不是OOM了？
auto compact 是下面的参数么？ 默认好像是开着的。
我测试环境配的内存比较少，找给了2gb给rockdb~~
现在执行完compact之后，是不是只能等了，等compact完之后，tag index 的状态会更新么？
compact执行完了之后重新rebuild就可以了，不过看内存确实少了点，搞不好还会oom。
为了避免OOM，可以把这个参数改小点
rebuild_index_batch_num
重建索引的时候有加off line参数咯？
加了，后面问题发现了，rebuild之前，挂了一个storage节点，虽然成功了，但是部分数据不可见。再拉起storaged之后，删除原索引，并重建rebuild之后，数据查询正常。
那因该就是这个问题，vertex是根据part的hash值分布的，某个part挂了，会导致数据查不到。
part不是有副本的么，针对索引part副本不会有效么？
很好的问题，也是很好的建议。nebula的多副本是被分配到了多个节点上，但是这个问题往往出现在part的选举和被选举的阶段，这个阶段相当于没有leader存在，所以导致了这个问题。后续我们将考虑协议层的retry机制来解决这个问题。
您好，rebuild_index_batch_num大小与数据量以及内存大小有述职参考吗？
