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

问答 问题
1

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)是每一行平均插入的时间吗？这些参数能否作为数据批量插入的指标？

2

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

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

3

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

4

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

5

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

1 个赞
6

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

7

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

9

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

1 个赞
10

大佬，我现在在测试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(...),...
11
  1. 你开了自动 compact 没有。
  2. 100000 的 batchSize 太大了，如果有大量写，来不及 compact，那就有可能会阻塞写的。
12

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

13

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

14

好滴

15

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

16

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

17

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

18

报错是什么错，graph 和 storage 有日志么？

19

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

20

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

21

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