这是由社区用户——繁凡撰写的一篇他的实践分享,主要讲解如何进行 Nebula 性能测试以及数据导入部分的性能调优。下文中出现的“我”代指用户繁凡。
之前在做 Nebula 的调研工作,然后又针对使用上做了性能测试,期间多次请教了 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 节点。
本次导入的数据数据结构为 7 种点类型、15 种边类型,数据量并不大,结构也很简单,数据量总计 3400w,不过要提前处理成这么多个点边表。
先创建 space,设置 vid=100 ,replica_factor=3,partition_num=100。
使用 [nebula-importer]进行导入,直接开干,速度只有 3w/s 的样子,这也太慢了吧。查看import的文档,整个使用的参数也就只有concurrency
,channelBufferSize
,batchsize
先调整一下试试吧,随便改了改,效果并不明显, 发帖请教大佬了。详见论坛帖子 [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 的个数都有影响,但还未尝试
根据业务上使用的指标,选取了一个进行测试。
指标如下:
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。
猜测可能是由于增加 graphd 之后没有 blance 或者 compact,有空可以尝试一下。
另外由于没有使用一些监控组件,只用了 Linux 的命令查看,所以也没有得到太确切的机器状态信息。
测试之前,保证集群的负载平衡,做好 compact
适当调整 storage 的配置,增大可用线程数以及缓存的内存大小
并发跟数据有很大关系的,单纯多少没有意义,需要结合自己的数据分布情况来看。
下边直接贴一下我修改的参数,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 也表现了很好的结果。具体参数的调整,也没有研究特别透彻,需要之后在使用中研究,如果大家有调优的好想法还请畅所欲言。