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

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

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

多少呢。。。

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

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

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

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

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

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

这个什么硬盘?

hdd的

做了Raid几?

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

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

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

是。

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

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

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

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

1赞

浙ICP备20010487号