nebula 2.0GA 多线程批量实时写入性能下降

问答 问题
1
  • nebula 版本： 2.0.0 GA
  • 部署方式: 分布式
  • 硬件信息
    • 磁盘 40T
    • CPU 40c
    • 内存 256

问题：
使用java client 批量写入数据，每批次约200条数据
单线程每秒插入顶点约为6w/s ，边是 4.5w/s
三线程每秒插入顶点约为12w/s , 边是 9w/s
六线程下降的比较厉害，这一块大概是什么原因呢

2

多少呢。。。

3

问下，你的分布式是怎么部署的？多加meta，多加storage对导入速度有提升吗？
我现在现在两个graph比原来单机部署时候速度还慢。

5

六线程的时候顶点的写入只有7w/s ，边的写入6w/s

6

多加storage 和 graph 对写入有提升的

7

关compaction比其他操作都有效的多

8

观测一下CPU是否跑满了？如果3线程时CPU已经接近全负载了，再加线程的效果就不大了。

9

我测试结果 100w无属性点 单机k线程，每个线程起SyncConnection
k=40 要17~18s 而且无论是对单个graphd写，还是各20 20对两个graphd写，没有区别
我不知道为什么速度这么慢

10

这个什么硬盘？

11

hdd的

12

做了Raid几？

13

请问raid50，会影响导入速度不？
另外，发现3个节点集群的导入速度比7个节点集群的导入速度快很多。集群节点数量增多以后，导入速度是否呈下降趋势？

14

猜测：
你partition数量不够，或者leader不均匀，或者就是客户端向同一个graphd发压力了。

15

分区数量：35，是节点数量的5倍，是官网推荐的倍数。您的意思是，导入数据的请求要尽量分散打到多个graphd上？

16

是。

因为Nebula 设计时候没有写入的中心节点，我之前的使用经验也不存在规模扩大速度反而慢的情况。

所以我只能猜测是不是测试本身导致了单点。 比如leader不均匀，或者只写入了同一个graphd。

另外写入时候一般是disable_auto_compact，否则HDD会严重放大这个问题。

HDD 加了 raid 感觉也没有太大意义，HDD就是不太跑的通。随机读还是太慢了。

1 个赞