hugegraph-server和loader的内存占用问题，以及性能问题

[mengquanrun]

Expected behavior 期望表现

内存占用低一些，性能更好一些
希望我有优化的空间，并且想请问贵团队在处理大型数据建图时，会采用什么策略呢？

Actual behavior 实际表现

内存占用居高不下
loader传输数据时，后期非常缓慢
并且最终报错
Edges has been imported:555144377
A fatal error has been detected by the Java Runtime Environment:

[thread 140403401385728 also had an error]
SIGBUS (0x7) at pc=0x00007fb22fdf64e2, pid=2670, tid=0x00007fb1f6bed700

JRE version: Java(TM) SE Runtime Environment (8.0_181-b13) (build 1.8.0_181-b13)
Java VM: Java HotSpot(TM) 64-Bit Server VM (25.181-b13 mixed mode linux-amd64 compressed oops)
Problematic frame:
C [libzip.so+0x124e2] newEntry+0x62

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

[ timer expired, abort... ]
这是什么缘故呢？

Steps to reproduce the problem 复现步骤

数据总量150G，两种label的边分别为78G和64G，近7亿条边，顶点3G，共6千万顶点
使用loader传输时，server和loader长时间共占用30G内存，且当edge imported达到5亿4千万时，传输速度会非常慢
loader命令 bin/hugegraph-loader -g hugegraph -f ethereum/struct.json -s ethereum/schema.groovy -h 192.168.1.2 -p 7878

Status of loaded data 数据状态

Vertex/Edge summary 数据量

• loaded vertices amount: 65 milion
• loaded edges amount: 0.7 bilion
• loaded time: 还未完成，预计24h+

Vertex/Edge example 数据示例

边数据：
{“source_address”:"xxxxxxxxx","target_address":"xxxxxxxxxx","name":"xxxxxxxxxxxxxxxx","money":xxx}

Specifications of environment 环境信息

• hugegraph version: 0.7.4
• operating system: ubuntu 16.04, 64 CPUs, 64G RAM
• hugegraph backend: rockDB

[mengquanrun]

10.22的issue提交似乎出了些问题，我不知道自己是否提交成功，所以连续提了几个相同的问题。。现在在尝试看看我的comment是否能成功

[javeme]

@mengquanrun 我们昨天也遇到了这个issue重复提交问题，没关系的。Github Incident: https://blog.github.com/2018-10-21-october21-incident-report/

[javeme]

@mengquanrun SIGBUS可能是内存不够导致的，希望再提供如下信息：发生错误的时候server单独占用的内存是多少？server JVM分配的最大内存是多少？

@Linary 帮忙复现及分析一下这个问题。

[mengquanrun]

@javeme 应该不是内存不够导致的，发生错误时系统还有14G内存可用，server单独占用内存应该在20G多一些，loader占用内存在10G多一些，server JVM的最大内存我没有自行设置，应该是默认的配置，我现在无法快速再次复现，因为传输时间太长，昨天传输了6个小时大概，最后报错，之后还导致了磁盘挂载出错，最后重启了服务器才解决，不过这个问题应该是我的磁盘写入方式有问题
另外是否可能因为我没有设置indexlabel，导致建图时的速度很慢？

[javeme]

@mengquanrun 看了详细的错误信息，看起来是触发了JVM的这个BUG导致的：https://bugs.openjdk.java.net/browse/JDK-8191484 ，是否在运行过程中Overwrite了什么文件呢？

[mengquanrun]

@javeme 抱歉我不是很懂java，那我该怎么办可以避免这个bug呢？
运行过程中应该没有覆盖什么文件吧，我只是正常的使用loader这个工具，我把rocksdb删除，初始化数据库然后再传一次?
另外贵团队在大型数据建图时，是如何提高后期edge import的速度呢？通过在schema中建立indexlabel之类的？还是没有办法。。因为数据太大，只能静待它自己传输完成？

[javeme]

@mengquanrun 建议再传一次，希望能找到明确的复现过程，那样比较好进一步分析。

后期导入速度变慢可能的原因很多，下面是常见的几种：

1. 批量插入失败时（比如某一条数据不符合规范），loader会尝试以单条模式进行重试，如果批量插入的非法数据过多可能导致后期缓慢；
2. 使用单块磁盘持续导入过多数据时，RocksDB因为compaction可能导致速度变慢（write stall）；
3. JVM分配内存不足可能导致速度变慢。

请确认：

1. 对于case 1，请看看日志目录中的错误内容是否过多，以及后期是否进度每500条变动一次。针对该问题我们后续会改进loader，请关注：单条插入任务超时时仍然有可能导致统计出错 incubator-hugegraph-toolchain#11
2. 对于case 2，请查看rocksdb日志来确认，需要具体分析哪一部分数据导致缓慢进而进行优化
3. 对于case 3，可通过调用任意查询API来查看是否server响应缓慢

[mengquanrun]

@javeme 好的，非常感谢，我再传一次试试看～明天上午才能给出复现结果了～

[mengquanrun]

该问题已得到解决，应该是单块磁盘长时间读写，会导致后期数据传输变慢，并且最后哦无力负担，磁盘挂掉。
如想使用rocksdb传输大量数据，比如5亿+的边数据，建议大家可以讲数据文件划分成两个小一点的文件，分别传输；我的测试条件下，顶点6千五百万，边数据5千万后会变得极度缓慢，当到达6亿1千万条之后，磁盘传输就会挂掉

[zhoney]

@mengquanrun 磁盘挂掉具体是什么表现呢？有报错信息的话麻烦提供一下。

另外，你的使用场景是loader和HugeGraphServer在同一台服务器上，且导入的原始数据和存放图数据的RocksDB数据目录都是同一块盘，是吗？

使用loader导入数据的两点建议：

1. 数据量很大时（亿以上），loader和HugeGraphServer分别使用不同的服务器。避免loader和HugeGraphServer因争用CPU和内存资源相互影响性能和程序稳定性。
2. 原始数据和图数据的存储使用不同的磁盘，尤其是数据量特别大时，RocksDB还可以使用多块盘降低磁盘压力，提升导入速度。

[mengquanrun]

@zhoney磁盘挂掉会返回io-exception，其他的信息就没有了。
是的，数据都在一块磁盘上。。。那我一会回去尝试一下。
另外请问这种情况下，数据总量150G，我是应该用尽量分布式做后端存储是么？
loader工具直接部署在另一台服务器上，它是http与server连接？所以我只要配置好h和p参数就ok了是么~

[zhoney]

@mengquanrun

另外请问这种情况下，数据总量150G，我是应该用尽量分布式做后端存储是么？

如果数据量稳定在当前规模，或者增长速度很慢的话，是可以使用RocksDB的。（数据没有备份的情况下，要考虑存储的高可用，防止数据丢失）

loader工具直接部署在另一台服务器上，它是http与server连接？所以我只要配置好h和p参数就ok了是么~

是的。loader是通过调用hugegraph-client通过http跟HugeGraphServer交互的。在不同的机器上时需要配置-h和-p参数

[mengquanrun]

@zhoney 好的，感谢

[mengquanrun]

@javeme @zhoney 抱歉还要请教一个问题，使用loader传输数据，长时间写入后，总是会导致磁盘过热，然后挂掉。。。
按照之前的建议，尝试了server和loader在不同机器上，并把文件分为20G左右的大小进行单独上传，但在写入大概100G时磁盘就会挂掉。。磁盘信息：英特尔760p 1T，存储后端RocksDB，server：0.7.4

请问您们在传输比如150G大小的数据文件时，会采用什么传输策略呢？

[wenzhenghu]

rocksdb的compaction问题，可以通过调整下writestall触发阈值来延后。只要磁盘空间够的话，应该可以缓解laod过程卡住问题 可参考 https://www.jianshu.com/p/a2892a161a7b Tuning RocksDB - Write Stalls

[github-actions]

Due to the lack of activity, the current issue is marked as stale and will be closed after 20 days, any update will remove the stale label