我正在将数据批量导入到服务器模式下运行的neo4j实例中（我运行过2.2.0社区和企业版以及2.1.7社区）。我的应用程序在内存中创建了一堆节点，并将停止写入一系列.csv文件，并将密码发送到neo4j实例以上传文件。（这是由于使用普通的旧REST API运行应用程序时出现性能问题）。
总的来说，我希望上传大约1.5亿至5亿个节点，所以原则上，这是neo4j声称能够相对较好地处理的事情。
不管怎样，当我针对生产数据运行这个程序时，我注意到应用程序在两种状态下运行——一种是csv上传每秒处理2k-8k个节点，另一种是每秒处理80-200个节点。当你把上传看作一个时间序列时，这两种状态是交织在一起的，随着时间的推移，它在缓慢状态下花费的时间越来越长。
节点是通过一系列创建的
MERGE (:{NODE_TYPE} {csvLine.key = n.primaryKey}) on create set [PROPERTY LIST];
语句，并且我对正在进行合并的所有内容都有索引。这感觉不像是插入语句的退化，因为减速不是线性的，而是双峰的，这感觉就像在neo4j实例中有垃圾收集。对于频繁的大容量插入，调优neo4jJVM垃圾收集器的最佳方法是什么？
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
这感觉就像是整个堆内存和新存储的最佳点。增加整体堆会降低性能。也就是说，neo4j垃圾收集日志经常有GC（分配失败）消息。
编辑：回应Michael Hunger:
这台机器有64GB的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行时，这似乎最大限度地提高了性能，这意味着实际上，周期性提交可以关闭
我没有在雄蕊上跑剖面图。我会这么做的，但我认为使用MERGE可以避免急切的merget问题。。。关于create语句。
一般来说，您的配置看起来不错，您的机器有多少RAM？
对于合并的内容，我建议使用约束而不是索引。
你的tx尺寸是多少？你运行了多少并发tx？
您可以共享具体的语句，而不是通用的merge语句（不会编译）吗？
你对这些陈述做了简介吗？也许你遇到了迫切的管道问题：
http://www.markhneedham.com/blog/2014/10/23/neo4j-cypher-avoiding-the-eager/
你使用定期提交吗？
您的CSV文件有多大？
请参阅：http://neo4j.com/developer/guide-import-csv/