详解 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的文档，整个使用的参数也就只有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 的个数都有影响，但还未尝试

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。

猜测可能是由于增加 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 也表现了很好的结果。具体参数的调整，也没有研究特别透彻，需要之后在使用中研究，如果大家有调优的好想法还请畅所欲言。