V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NebulaGraph
V2EX  ›  推广

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

  •  
  •   NebulaGraph · 147 天前 · 138 次点击
    这是一个创建于 147 天前的主题,其中的信息可能已经有所发展或是发生改变。

    详解 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 报名传送门,我们在北京等你来交流~~

    目前尚无回复
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4032 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 02:58 · PVG 10:58 · LAX 18:58 · JFK 21:58
    ♥ Do have faith in what you're doing.