垃圾收集调整/性能下降neo4j批量.csv导入

我正在运行批量导入数据到一个neo4j实例（我运行在2.2.0社区和企业版以及2.1.7社区）运行在服务器模式。我的应用程序在内存中创建了一堆节点，并且会按时周期停下来编写一系列.csv文件并将密码发送到neo4j实例以上载文件。（这是由于使用普通的旧REST API运行应用程序时出现的性能问题）。垃圾收集调整/性能下降neo4j批量.csv导入

总的来说，我期待上传类似150-5000万个节点的东西，所以这是原则上neo4j声称能够处理得相当好的东西的类型。

好吧，无论如何，当我针对生产数据运行时，我注意到的是，应用程序运行在两种状态 - 一种是csv上载每秒处理2k-8k节点，另一种是处理它的进程每秒80-200个节点。当你将上传视为一个时间序列时，这两个状态是交织在一起的，随着时间的推移，它在慢速状态下花费的时间越来越长。

节点通过一系列

MERGE (:{NODE_TYPE} {csvLine.key = n.primaryKey}) on create set [PROPERTY LIST];

语句创建的，我有我做的合并对一切指标。这并不像插入语句中的降级，因为减速不是线性的，而是双峰的，这就像neo4j实例中有垃圾收集一样。调整neo4j JVM垃圾收集器进行频繁批量插入的最佳方式是什么？

neo4j.properties：

neostore.nodestore.db.mapped_memory=50M 
neostore.relationshipstore.db.mapped_memory=500M 
#neostore.relationshipgroupstore.db.mapped_memory=10M 
neostore.propertystore.db.mapped_memory=100M 
#neostore.propertystore.db.strings.mapped_memory=130M 
neostore.propertystore.db.arrays.mapped_memory=130M

的Neo4j-wrapper.conf：

wrapper.java.additional=-XX:+UseConcMarkSweepGC 
wrapper.java.additional=-XX:+CMSClassUnloadingEnabled 
wrapper.java.additional=-XX:-OmitStackTraceInFastThrow 
wrapper.java.additional=-XX:hashCode=5 

wrapper.java.initmemory=8194 
wrapper.java.maxmemory=8194

这感觉就像甜蜜点都整体堆内存和neostore东西。增加整体堆降低性能。也就是说，neo4j垃圾收集日志经常会有GC（分配失败）消息。

编辑：响应迈克尔饥饿：

该机拥有64 GB的RAM，并且似乎没有任何被刷爆。它似乎也只是在任何时候只使用少量的内核。垃圾收集器分析显示垃圾收集器似乎运行频繁。

确切暗号语句，例如：

USING PERIODIC COMMIT 110000 LOAD CSV WITH HEADERS FROM 'file:///home/jschirmer/Event_2015_4_773476.csv' AS csvLine MERGE (s:Event {primaryKey: csvLine.primaryKey}) ON CREATE SET s.checkSum= csvLine.checkSum,s.epochTime= toInt(csvLine.epochTime),s.epochTimeCreated= toInt(csvLine.epochTimeCreated),s.epochTimeUpdated= toInt(csvLine.epochTimeUpdated),s.eventDescription= csvLine.eventDescription,s.fileName= csvLine.fileName,s.ip= csvLine.ip,s.lineNumber= toInt(csvLine.lineNumber),s.port= csvLine.port,s.processPid= csvLine.processPid,s.rawEventLine= csvLine.rawEventLine,s.serverId= csvLine.serverId,s.status= toInt(csvLine.status); 

USING PERIODIC COMMIT 110000 LOAD CSV WITH HEADERS FROM 'file:///home/jschirmer/Event__File_2015_4_773476.csv' AS csvLine MATCH (n:SC_CSR{primaryKey: csvLine.Event_id}), (s:File{fileName: csvLine.File_id}) MERGE n-[:DATA_SOURCE]->s;

虽然有正在取得我已经尝试了单个并发事务以及运行serveral的这样的语句数（〜3）这样的语句并联（这提供了大约2倍的改进）。我试着调整定期提交频率和文件的大小。当csv文件大约为10万行时，这似乎最大化了性能，这意味着实际上，定期提交可以关闭。

我还没有运行在statables上的配置文件。我会这么做的，但我认为通过使用MERGE ...来避免急切的合并问题...在创建语句上。

来源

2015-04-06 Jerry Schirmer