详解 nebula 2.0 性能测试和 nebula-importer 数据导入调优

原创
07/12 14:15
阅读数 753

详解 nebula 2.0 性能测试和 nebula-importer 数据导入调优

这是由社区用户——繁凡撰写的一篇他的实践分享,主要讲解如何进行 Nebula 性能测试以及数据导入部分的性能调优。下文中出现的“我”代指用户繁凡。

0. 概要

之前在做 Nebula 的调研工作,然后又针对使用上做了性能测试,期间多次请教了 Nebula 的官方人员,在这里对官方人员表示感谢,大佬辛苦了!

我把自己测试的过程整理一下,希望对大家有一点启发,如果大家有更好的意见,请不吝赐教!

1.部署 Nebula 集群

首先准备了 4 台实体机:1、2、3、4,每台配置,CPU:96C,内存:512G, 磁盘:SSD。机子分配:

  • 1:meta,storage
  • 2:storage
  • 3:storage
  • 4:graphd

安装过程就不再详述了,使用的是 rpm 的方式。其他插件:nebula-import-2.0,nebula-bench-2.0,下载源码编译即可,安装在 4 节点。

2.导入数据

本次导入的数据数据结构为 7 种点类型、15 种边类型,数据量并不大,结构也很简单,数据量总计 3400w,不过要提前处理成这么多个点边表。

先创建 space,设置 vid=100 ,replica_factor=3,partition_num=100。

nebula-importer 数据导入优化

使用 nebula-importer 进行导入,直接开干,速度只有 3w/s 的样子,这也太慢了吧。查看import的文档,整个使用的参数也就只有concurrencychannelBufferSizebatchsize

先调整一下试试吧,随便改了改,效果并不明显, 发帖请教大佬了。详见论坛帖子 nebula-import 2.0 导入速度太慢,请教完之后,收获很大,先改 yaml 参数

concurrency:96 # cpu核数
channelBufferSize:20000
batchsize:2500

速度差不多 7-8w 了,嗯,看起来确实快了很多,再搞大点,graphd 直接崩掉了,看来还是不能过大,所以这几个参数要尽量大但是不能过大

然后再确认下磁盘和网络,竟然用的是机械磁盘和千 M 网络。。。改成SSD的,然后再切换成万 M 网络,速度直接再提升一倍多,大概 17w/s,看起来硬件还是很重要。

然后我再想会不会跟数据有关系,注意到 vid 和partition_num,vid 挺长的想着设置短一点但是没办法改,因为确实有这么长的,然后是 partition_num,看了下官方说明,磁盘的 2-10 倍,改为了 15,确实有影响,速度达到了 25w/s。到这里也算比较满意了,可能再修改还会有提升,不过已经满足要求了先告一段落吧。

小结

  • concurrency 设置为 CPU 核数,channelBufferSize 和 batchsize 尽可能大,但是不能超过集群的负载。
  • 硬件要用 SSD 和万 M 网络
  • space 的分区 partition_num 要合理,不能太多
  • 猜测 vid 长度,属性数量,graphd 的个数都有影响,但还未尝试

3.压力测试

根据业务上使用的指标,选取了一个进行测试。 指标如下:

match (v:email)-[:emailid]->(mid:id)<-[:phoneid]-(phone:phone)-[:phoneid]->(ids:id) where id(v)=="replace" with v, count(distinct phone) as pnum,count(distinct mid) as midnum,count(distinct ids) as idsnum , sum(ids.isblack) as black  where pnum > 2 and midnum>5 and midnum < 100 and idsnum > 5 and idsnum < 300 and black > 0 return v.value1, true as result

该语句为一个三度扩散 + 条件判断,集中数据涉及点的数量大概在 200-400 之间。

官方的 nebula-bench 需要做一点修改,打开 jmter 的 go_step.jmx 配置文件,修改ThreadGroup.num_threads为 CPU 核数,然后是其他的参数,如 loop,ngql 根据实际情况设置,ngql 里边的变量要用 replace 代替。

由于测试数据为较为集中的数据,该部分测试结果为 700/s,将数据扩大至全部节点,则达到 6000+/s。并发看起来还是可以的,查询速度也 ok,最高 300ms。

因为我这里是单节点,所以想增加 1 台 graphd 进行测试,看并发是否提高,然后直接启动了一个graphd进程,再测试结果发现没有提高。

然后刚好看到发布了2.0.1,所以重新搭建了集群,重新导入数据,使用 3 台 graphd,性能直接翻三倍,集中数据达到2100+/s,全部节点则达到将近 2w。所以很奇怪,详见论坛帖子nebula-bench 2.0 增加graph节点,并发上不去

猜测可能是由于增加 graphd 之后没有 blance 或者 compact,有空可以尝试一下。

另外由于没有使用一些监控组件,只用了 Linux 的命令查看,所以也没有得到太确切的机器状态信息。

小结

  • 测试之前,保证集群的负载平衡,做好 compact
  • 适当调整 storage 的配置,增大可用线程数以及缓存的内存大小
  • 并发跟数据有很大关系的,单纯多少没有意义,需要结合自己的数据分布情况来看。

4.配置

下边直接贴一下我修改的参数,meta,graphd 都采用默认配置,也没有特别要修改的,只贴一下 storage,并进行说明。

rocksdb_block_cache=102400  # 官方建议 1/3 内存,我这里设置 100G
num_io_threads=48 # 可用线程数,设置为 cpu 核数一半
min_vertices_per_bucket=100 # 一个桶最小的点数量
vertex_cache_bucket_exp=8 # 桶的总数是 2 的 8 次方
wal_buffer_size=16777216  # 16 M

write_buffer_size:268435456   # 256 M

这里的参数是根据浏览各个贴子以及去官方代码查找的,并不一定特别准确,也是摸索来的,其他的参数没有特别修改。有很多的参数没有暴露出来,官方不建议随便修改,所以需要了解的话要去 GitHub 的源码里边查看。

结尾

总体来说,本次测试算不上特别专业,但是针对具体业务场景的测试,Nebula 也表现了很好的结果。具体参数的调整,也没有研究特别透彻,需要之后在使用中研究,如果大家有调优的好想法还请畅所欲言。

交流图数据库技术?报名参与 Nebula 交流会,NUC·2021 报名传送门,我们在北京等你来交流~~

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部