- nebula 版本：v1.2.0
- 部署方式（分布式 / 单机 / Docker / DBaaS）：Docker * 3
- 硬件信息
- 磁盘（ 必须为 SSD ，不支持 HDD） SSD * 1T * 3
- CPU、内存信息：12c24g * 3
- 出问题的 Space 的创建方式：N/A ;
- 问题的具体描述
按照 文档上的内存估算资源估算
我们的使用情况是三副本标准配置。
点边数量大概是 3.4e9(34亿), write_buffer_size(default:64M)、max_write_buffer_number(default:4)、rocksdb_block_cache(default:1024M)
都是默认的配置
最开始的时候，没有设置enable_partitioned_index_filter参数，开始启动的时候单节点内存使用大概是9G，然后当我们开始大批量的导入数据的时候，内存一直在上涨。
写入速度大概10w/s(点和边的插入)，
导入过程中内存一直在缓慢增加，大概在导入6个小时之后，触发了docker的container内存限制（memory limit 16G），storaged的container被重启。
然后我们开始 添加了 将enable_partitioned_index_filter 参数设为true，将container的内存限制改为19G，然后重启storaged
启动后storaged的内存只有300M，之后我们开始导入剩下的9亿数据，导入完成之后，内存使用稳定在了4.6G
对于之前我在另外一个帖子中出现的问题
RaftPart buffer is full
我现在也怀疑是内存的使用问题，因为我们之前的实例上创建列两个space，一个是三副本的，一个是单副本的，数据量（点+边）都是34亿，算下来 (3.4e9 *15)*(4/3) + 3 * (4 * 64*1024*1024) + 1024*1024*1024 * 3 = 67G 也差不多到了我们集群的内存限制了（单台配置是24G内存，实际可用也就22-23G）。但是有一点没有搞明白的是在大批量导入历史数据的时候，内存不够用了会直接被docker kill掉然后重启，但是之前在写入实时数据的时候storaged进程 并没有被kill，而是一直出现 报 RaftPart buffer is full 和 Fail to update vertex 。当然这只是我的猜测，如果之后按照这个思路能够复现问题，我再给出更详细的信息。
针对以上的现象，我想请教几个问题：
- 1、文档中的enable_partitioned_index_filter参数添加之后，该如何评估内存的使用情况？
- 2、现在我们的情况是如果开启enable_partitioned_index_filter，内存使用率不高（当前4.6G/22G），如果不开启这个参数，内存估计就超过集群的限制。所以不知道以下两个策略会对性能造成什么影响。
- 2.1 enable_partitioned_index_filter=false ，开启虚拟内存（swap）
- 2.2 enable_partitioned_index_filter=true，增加 rocksdb_block_cache 和 write_buffer_size
- 3、我还注意到了compact操作 ,文档中提到了
自动 compact 会在系统有读写或者重启时自动进行，以提升短时间内的读速度。
我想问两个问题:- 1、“短时间内是”具体是个什么数量级，或者说该怎么评估这个时间？
- 2、compact优化只是在读硬盘上的优化还是有命中缓存的优化？