Star

nebula-storage 内存与性能的问题

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

还有一个问题请教一下,我看到了这个回答 enable_partitioned_index_filter的读取性能影响 有下面的描述
经常读的数据和不经常读的数据比例在82开的话,经验上说影响很小
这个意思是指

  • 1、经常读的数据在整体数据中的占比
  • 2、某次查询所读取的数据中经常读的数据和不经常读的数据比例82开

我理解的经常读就是大概率能命中缓存,如果缓存策略是LRU机制,经常读我就可以理解为最近有使用(增加或者查询)的数据,如果是这样那对我们的应用场景还是挺友好的

@valseek 非常感谢你这么认真提的问题,问题描述清楚详细!
@critical27 帮忙回答下。

1赞
  1. 参见rocksdb的文档, 打开配置后分两层,然后L0的会pin在block cache中。
  2. 内存有限制的话强烈建议enable_partitioned_index_filter=true
  3. 短时间得用户测,跟你写入速率有关,比如没有写入,“短时间”就变的很长。可以去了解下rocksdb compact的机制以及读路径。

PS: RaftPart buffer is full 和以上都没有任何关系,我在另外那个帖子回过了,就是同一个partition的数据同时导入太多,最简单导入过程中就只写同一个点或者同一条边。

浙ICP备20010487号