Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mengquanrun opened this issue Oct 22, 2018 · 15 comments

Comments

@mengquanrun
Copy link

@mengquanrun mengquanrun commented Oct 22, 2018

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

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Oct 22, 2018

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

@javeme

This comment has been minimized.

Copy link
Contributor

@javeme javeme commented Oct 23, 2018

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

@javeme

This comment has been minimized.

Copy link
Contributor

@javeme javeme commented Oct 23, 2018

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

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

@mengquanrun

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Oct 23, 2018

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

@javeme

This comment has been minimized.

Copy link
Contributor

@javeme javeme commented Oct 23, 2018

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

@mengquanrun

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Oct 23, 2018

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

@javeme

This comment has been minimized.

Copy link
Contributor

@javeme javeme commented Oct 23, 2018

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

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

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

请确认:

  1. 对于case 1,请看看日志目录中的错误内容是否过多,以及后期是否进度每500条变动一次。针对该问题我们后续会改进loader,请关注:hugegraph/hugegraph-loader#11
  2. 对于case 2,请查看rocksdb日志来确认,需要具体分析哪一部分数据导致缓慢进而进行优化
  3. 对于case 3,可通过调用任意查询API来查看是否server响应缓慢
@mengquanrun

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Oct 23, 2018

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

@mengquanrun

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Oct 27, 2018

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

@zhoney

This comment has been minimized.

Copy link
Contributor

@zhoney zhoney commented Oct 29, 2018

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

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

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

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

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Oct 29, 2018

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

@zhoney

This comment has been minimized.

Copy link
Contributor

@zhoney zhoney commented Oct 29, 2018

@mengquanrun

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

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

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

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

@mengquanrun

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Nov 5, 2018

@zhoney 好的,感谢

@mengquanrun

This comment has been minimized.

Copy link
Author

@mengquanrun mengquanrun commented Nov 7, 2018

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

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

@wenzhenghu

This comment has been minimized.

Copy link
Contributor

@wenzhenghu wenzhenghu commented May 29, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.