Question

我正在运行以服务器模式运行的neo4j实例（我已经运行2.2.0社区和企业版以及2.1.7社区）批量导入数据。我的应用程序在内存中创建了一堆节点，并且将永久停止编写一系列.csv文件并将cypher发送到neo4j实例以上传文件。（这是由于使用普通的旧REST API运行应用程序的性能问题而完成的）。

总的来说，我希望上传类似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（Allocation Failure）消息。

编辑：回应迈克尔·亨格：

该机器有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;

虽然有几个这样的陈述我尝试了一个并发事务，并且并行运行了几个（~3个）这样的语句（大约提高了2倍）。我已经尝试调整周期性提交频率和文件大小。当csv文件大约是100k行时，这似乎最大化了性能，这意味着，实际上，定期提交可以关闭。

我没有在staments上运行个人资料。我会这样做，但我认为通过在创建语句上使用MERGE ...可以避免急切的合并问题。

Answer 1

一般情况下，您的配置看起来没问题，您的机器有什么内存？

对于您合并的内容，我建议使用约束而不是索引。

你的tx大小是多少？你运行了多少并发tx？

您可以共享具体的语句，而不是您的通用合并语句（不会编译）吗？

您是否对这些陈述进行了描述？也许你遇到了急切的管道问题：

http://www.markhneedham.com/blog/2014/10/23/neo4j-cypher-avoiding-the-eager/

您是否使用定期提交？

您的CSV文件有多大？

请参阅：http://neo4j.com/developer/guide-import-csv/

neo4j bulk .csv import的垃圾收集调整/性能下降

1 个答案: