nebula importer工具输出日志相关参数的疑问

nebula 版本:v2.0.0
nebula importer版本:v2.0.0对应版本
部署方式:分布式
是否为线上版本:Y

  • 问题的具体描述
    使用nebula importer自带的例子进行数据导入成功,然后对输出在终端的日志有几处需要解答一下
INFO: readr.go:180:Total lines of file (.../v2/student.csv) is: 3, error lines: 0
INFO: startmgr.go:61: Done (.../v2/student.csv): Time(8.11s), Finised(55), Failed(0), tatency AVG(1619us), Batch Req AVG(2036us), Rows AVG(6.78/s)

其中,Time(8.11s)是表示插入student.csv中的三条数据需要的时间吗?Finesed(55)表示的是什么意思?Rows AVG(6.78s)是每一行平均插入的时间吗?这些参数能否作为数据批量插入的指标?

Time(8.11s) 是插入 55 条数据的时间,你应该不只有一个文件把。
Rows AVG(6.78/s) 是一秒插入多少条,55/8.11。

不清楚你什么样的批量插入指标,数据导入还和并发数,batch 大小有关系。

并发数为2, batchsize为2,有13个文件。
但是这里显示的不是插入student.csv的时间吗?跟其他文件有关系吗,还有就是在配置文件中对同一个文件配置两次,会对其进行两次插入吗,这两次插入的时间是算在同一个student.csv导入的时间不。

import 一次导入配置文件里的所有文件,不是只针对某一个 csv 文件,你可以看一下日志还是有其他的文件的。
会插入两次

可能是因为这个 typo 影响了你理解,实际上应该是 Finished(55),要不要顺手去 nebula-importer repo 提个 pr 修复一下? :grin: Nebula 马克杯等着你

1 个赞

哈哈哈哈,见笑了见笑了,我理解这个了。顺便再问一下,有32个processor,每个processor有8个core,并发数设置成32*8应该是可以的吧。

从客户端是可以的,但是你需要试一下会不会给服务端太大的压力。
你可以调整 batch Size 的大小,试一下,如果服务端报错,结果里有会统计的。

256的并发,确实有写入失败的情况,原因是Storage的错误,不过写入失败的数据会放到csv文件真的棒棒。按照你提供的思路,把并发降到128(从日志发现它其实开了256个客户端),写入6000w数据杠杠的,我写了个性能测试的报告,好想分享出来,可惜是内网的环境,哈哈哈。

1 个赞

大佬,我现在在测试nebula graph的可扩展性,主要测试它的导入以及查询的性能。首先在单台机器下面进行测试,然后增大数据量,使用集群测试。
版本信息

  • nebula 版本:v2.0.0
  • nebula importer版本:v2.0.0对应版本
  • 部署方式:单机
  • 是否为线上版本:N

硬件信息

  • 机器:el6.x86_64
  • processor:32
  • cores:8
  • 带宽:1000MB/s
  • 磁盘:HHD

nebula importer yaml配置信息

  • concurrency:64
  • channelBufferSize:100000
  • batchSize:100000

space信息(12为磁盘数量)

  • 分片数:12*5
  • 备份数:1
  • VID: FIXED_STRING(10)

文件描述(一共四个文件)

  • 学生文件:1亿个点
  • 课程文件:33个点
  • 学生之间关系文件:4亿条边
  • 学生与课程之间的关系文件:1亿条边

使用问题描述

  • 前面插入的时候还正常,插入速度能够保持在17w/s的插入速度,当数量上去的时候,第一是有插入失败的情况,第二是很久都不进行插入。

报错的情况

ErrMSG: StorageError: part33, error: E_RPC_FAILURE(-3), ErrCode:-8

插入很久的情况

Tick: Time(4430s), Finished(358337535), Failed(...),...
...
Tick: Time(4505s), Finished(358337535), Failed(...),...
  1. 你开了自动 compact 没有。
  2. 100000 的 batchSize 太大了,如果有大量写,来不及 compact,那就有可能会阻塞写的。

可以在执行过程中,开启监控,主要看一下网络和磁盘写的情况。

我没有设置自动compact,我看了一下文档,默认是开启的,我需要关闭自动Compact吗

好滴

可以对比一下,如果默认开启 compact 的话,有可能影响写入速度。

还是上面的数据,不过现在数据量变成了10亿条点数据,50亿条边数据。配置也还是上面的配置,不过是加入了一台机器,组成了集群。并发是56,channelBufferSize:10000,batchSize:5000,关闭了自动compact。刚开始的时候写入的速度每秒大概有50w条,随着时间的推移速度慢慢下降,写到7-8 亿条的时候就开始会有插入错误,在过一会,就会大量报错,最后退出nebula-importer进程。请问有什么好的解决办法吗?(我的尝试:降并发,降channelBufferSize,batchSize也还是会有同样的问题)

不过我注意到一个现象,刚开始写入速度在四十万到五十万的时候,两台机器的磁盘写比较高,当写入速到降到十几万条每秒的时候,其中一台机器基本没有写了,不知道为什么会这样

报错是什么错,graph 和 storage 有日志么?

ErrMSG: StorageError: part33, error: E_RPC_FAILURE(-3), ErrCode:-8类似的错误

可能是在导入过程中,storage 处理不过来,然后报超时了。
你的磁盘是 SSD 的吧,可以适当调整一下 nebula-graph 的 storage_client_timeout_ms 参数,或者把 batchSize 再小一点。

导入到14亿的时候,nebula-importer的进程自动退出了。。。没有任何报错,日志全是正常的信息,show hosts集群状态也正常,这又是什么原因?配置不变。

浙ICP备20010487号