- 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优化只是在读硬盘上的优化还是有命中缓存的优化?