将记录添加到空间层后，Neo4J 性能大幅下降

【问题标题】：Neo4J huge performance degradation after records added to spatial layer将记录添加到空间层后，Neo4J 性能大幅下降
【发布时间】：2014-07-26 17:50:28
【问题描述】：

所以我有大约 7000 万条空间记录要添加到空间层（我用一小部分测试过，一切都很顺利，查询返回与 postgis 相同的结果，层操作似乎很好） 但是，当我尝试将所有空间记录添加到数据库时，性能会迅速下降，以至于在大约 500 万条（大约 2 小时运行时间）记录时它变得非常慢，并且挂起在 ~770 万条（经过 8 小时）。

由于空间索引是使用图结构构建自身的 Rtree，我想知道为什么当 os 记录数增加时它会降级。 如果我没记错的话，Rtree 插入是 O(n)，这就是为什么我担心它可能是重新排列边界框之间的问题，不是树叶的节点导致 addToLayer 过程随着时间的推移而变慢。

目前我正在向这样的层添加节点（很多硬编码的东西，因为我试图在模式和代码风格之前找出问题）：

Transaction tx = database.beginTx();
    try {

        ResourceIterable<Node> layerNodes = GlobalGraphOperations.at(database).getAllNodesWithLabel(label);
        long i = 0L;
        for (Node node : layerNodes) {
            Transaction tx2 = database.beginTx();
            try {
                layer.add(node);
                i++;
                if (i % commitInterval == 0) {
                    log("indexing (" + i + " nodes added) ... time in seconds: "
                            + (1.0 * (System.currentTimeMillis() - startTime) / 1000));
                }
                tx2.success();
            } finally {
                tx2.close();
            }
        }
        tx.success();
    } finally {
        tx.close();
    }

有什么想法吗？关于如何提高性能的任何想法？

ps.: 使用 java API Neo4j 2.1.2，空间 0.13 酷睿 i5 3570k @4.5Ghz，32GB 内存 数据库专用 2TB 7200 硬盘（无操作系统，无虚拟内存文件，只有数据本身）

ps2.：所有几何图形都是 LineStrings（如果这很重要 :P），它们代表街道、道路等。

ps3.: 节点已经在数据库中，我只需要将它们添加到图层中，这样我就可以执行空间查询，bbox 和 wkb 属性都可以，经过测试并适用于一小部分。

提前谢谢你

在修改并再次运行代码后（仅将点插入数据库需要 5 小时，不涉及层）发生这种情况，将尝试增加 jvm 堆和嵌入式图形内存参数。

indexing (4020000 nodes added) ... time in seconds: 8557.361
Exception in thread "main" org.neo4j.graphdb.TransactionFailureException: Unable to commit transaction
    at org.neo4j.kernel.TopLevelTransaction.close(TopLevelTransaction.java:140)
    at gis.CataImporter.addDataToLayer(CataImporter.java:263)
    at Neo4JLoadData.addDataToLayer(Neo4JLoadData.java:138)
    at Neo4JLoadData.main(Neo4JLoadData.java:86)
Caused by: javax.transaction.SystemException: Kernel has encountered some problem, please perform neccesary action (tx recovery/restart)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
    at org.neo4j.kernel.impl.transaction.KernelHealth.assertHealthy(KernelHealth.java:61)
    at org.neo4j.kernel.impl.transaction.TxManager.assertTmOk(TxManager.java:339)
    at org.neo4j.kernel.impl.transaction.TxManager.getTransaction(TxManager.java:725)
    at org.neo4j.kernel.TopLevelTransaction.close(TopLevelTransaction.java:119)
    ... 3 more
Caused by: javax.transaction.xa.XAException
    at org.neo4j.kernel.impl.transaction.TransactionImpl.doCommit(TransactionImpl.java:560)
    at org.neo4j.kernel.impl.transaction.TxManager.commit(TxManager.java:448)
    at org.neo4j.kernel.impl.transaction.TxManager.commit(TxManager.java:385)
    at org.neo4j.kernel.impl.transaction.TransactionImpl.commit(TransactionImpl.java:123)
    at org.neo4j.kernel.TopLevelTransaction.close(TopLevelTransaction.java:124)
    at gis.CataImporter.addDataToLayer(CataImporter.java:256)
    ... 2 more
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
    at org.neo4j.kernel.impl.nioneo.store.DynamicRecord.clone(DynamicRecord.java:179)
    at org.neo4j.kernel.impl.nioneo.store.PropertyBlock.clone(PropertyBlock.java:215)
    at org.neo4j.kernel.impl.nioneo.store.PropertyRecord.clone(PropertyRecord.java:221)
    at org.neo4j.kernel.impl.nioneo.xa.Loaders$2.clone(Loaders.java:118)
    at org.neo4j.kernel.impl.nioneo.xa.Loaders$2.clone(Loaders.java:81)
    at org.neo4j.kernel.impl.nioneo.xa.RecordChanges$RecordChange.ensureHasBeforeRecordImage(RecordChanges.java:217)
    at org.neo4j.kernel.impl.nioneo.xa.RecordChanges$RecordChange.prepareForChange(RecordChanges.java:162)
    at org.neo4j.kernel.impl.nioneo.xa.RecordChanges$RecordChange.forChangingData(RecordChanges.java:157)
    at org.neo4j.kernel.impl.nioneo.xa.PropertyCreator.primitiveChangeProperty(PropertyCreator.java:64)
    at org.neo4j.kernel.impl.nioneo.xa.NeoStoreTransactionContext.primitiveChangeProperty(NeoStoreTransactionContext.java:125)
    at org.neo4j.kernel.impl.nioneo.xa.NeoStoreTransaction.nodeChangeProperty(NeoStoreTransaction.java:1244)
    at org.neo4j.kernel.impl.persistence.PersistenceManager.nodeChangeProperty(PersistenceManager.java:119)
    at org.neo4j.kernel.impl.api.KernelTransactionImplementation$1.visitNodePropertyChanges(KernelTransactionImplementation.java:344)
    at org.neo4j.kernel.impl.api.state.TxStateImpl$6.visitPropertyChanges(TxStateImpl.java:238)
    at org.neo4j.kernel.impl.api.state.PropertyContainerState.accept(PropertyContainerState.java:187)
    at org.neo4j.kernel.impl.api.state.NodeState.accept(NodeState.java:148)
    at org.neo4j.kernel.impl.api.state.TxStateImpl.accept(TxStateImpl.java:160)
    at org.neo4j.kernel.impl.api.KernelTransactionImplementation.createTransactionCommands(KernelTransactionImplementation.java:332)
    at org.neo4j.kernel.impl.api.KernelTransactionImplementation.prepare(KernelTransactionImplementation.java:123)
    at org.neo4j.kernel.impl.transaction.xaframework.XaResourceManager.prepareKernelTx(XaResourceManager.java:900)
    at org.neo4j.kernel.impl.transaction.xaframework.XaResourceManager.commit(XaResourceManager.java:510)
    at org.neo4j.kernel.impl.transaction.xaframework.XaResourceHelpImpl.commit(XaResourceHelpImpl.java:64)
    at org.neo4j.kernel.impl.transaction.TransactionImpl.doCommit(TransactionImpl.java:548)
    ... 7 more

28/07 -> 增加内存没有帮助，现在我正在测试 RTreeIndex 和 LayerRTreeIndex 中的一些修改（maxNodeReferences 字段究竟做了什么？

// Constructor

public LayerRTreeIndex(GraphDatabaseService database, Layer layer) {
    this(database, layer, 100);     
}

public LayerRTreeIndex(GraphDatabaseService database, Layer layer, int maxNodeReferences) {
    super(database, layer.getLayerNode(), layer.getGeometryEncoder(), maxNodeReferences);
    this.layer = layer;
}

它被硬编码为 100，并且当我的 addToLayer 方法崩溃到 OutOfMemory 错误时（明智地添加节点数）更改其值，如果我没记错，更改该字段的值会增加或减少树的宽度和深度（比 50 宽 100，而 50 比 100 深）。

总结目前的进展：

  • @Jim 纠正的交易使用不正确
  • 根据@Peter 的建议，内存堆增加到 27GB
  • 需要 3 个空间层，但现在问题变得现实，因为它们是大空间层。
  • 在向空间层添加节点时进行了一些内存分析，我发现了一些有趣的点。

内存和 GC 分析：http://postimg.org/gallery/biffn9zq/

在整个过程中使用最多内存的类型是 byte[]，我只能假设它属于几何 wkb 属性（几何本身或 rtree 的 bbox）。 考虑到这一点，我还注​​意到（您可以查看新的分析图像）使用的堆空间量从未低于 18GB 标记。

根据这个问题are java primitives garbage collected java中的原始类型是原始数据，因此不会受到垃圾回收，并且仅在方法返回时从方法的堆栈中释放（所以也许当我创建一个新的空间层时，所有这些 wkb 字节数组将保留在内存中，直到我手动关闭图层对象）。

这有意义吗？有没有更好的方法来管理内存资源，使层不会保持未使用的旧数据加载？

【问题讨论】：

  • 你用的是什么图层类？
  • 这是一些分析信息，不知道是否有帮助CPU time methodsSelf time methodsCPU time classes
  • Google 指出 Neo4j rtree 实现存在一些问题。看起来可能有错误。
  • 看起来我在向空间层添加节点时遇到了一些奇怪的行为，通常在接近 400 万个节点时它会崩溃并出现异常

标签： neo4j r-tree neo4j-spatial


【解决方案1】：

卡塔卡瓦科，

您将每次添加都作为单独的事务进行。要使用您的 commitInterval，您需要将代码更改为类似的内容。

Transaction tx = database.beginTx();

try {
    ResourceIterable<Node> layerNodes = GlobalGraphOperations.at(database).getAllNodesWithLabel(label);

    long i = 0L;

    for (Node node : layerNodes) {
        layer.add(node);
        i++;

        if (i % commitInterval == 0) {
            tx.success();
            tx.close();

            log("indexing (" + i + " nodes added) ... time in seconds: "
                + (1.0 * (System.currentTimeMillis() - startTime) / 1000));

            tx = database.beginTx();
        }
    }

    tx.success();
} finally {
    tx.close();
}

看看这是否有帮助。

恩典与和平，

吉姆

【讨论】：

  • 我确实更改了它以测试我的瓶颈是否是 IO、磁盘使用或其他相关但严格来说是 CPU 使用，将其更改回测试但希望不大。
  • 提交间隔应该在 10k 到 50k 之间
  • 我已经应用了 Jim 的建议，提交间隔设置为 10k，仍然变慢，可能问题与事务无关，插入率从 0 到大约 4-5 百万（其中我意味着将现有几何图形添加到空间层）每批减少 0.6 秒（或大约每秒 16k 个节点），而在 500 万个标记之后直到 700 万个（它完全挂起）它逐渐下降直到每秒 10-20 个几何图形.
  • 也许如果我查询按边界框区域排序的节点（即使没有空间层也很容易计算），我可以先得到更大的节点，这样以后插入 RTree 就不会导致许多二次分割和 bbox 调整
  • 我期待听到您接下来的发现！
【解决方案2】：

查看Error java.lang.OutOfMemoryError: GC overhead limit exceeded，可能正在进行一些过多的对象创建。从你的分析结果看，它看起来不像，你能仔细检查一下吗？

【讨论】：

  • 重新检查了导入最后几层（较大的层）时的行为，似乎将索引节点爆炸到多个 bbox 中的操作，再加上堆的大小（10GB）使得GC 在每批之后不停地清理烂摊子。 PostGIS 中的相同索引（使用不同类型的 Rtree）最多可填充 7GB（仅索引），考虑到这一点，解决方案是进一步增加堆大小，现在运行在最小 8GB 和最大 27GB，GC活动已降至接近 0%（仍在运行，因为数据量很大，我目前在 ~200GB 中的 30GB）
  • 也许性能下降是在堆完全填满并且 GC 不得不超时工作为从 shapefile 读取的新数据腾出空间时发生的
  • 这将是一个非常好的高性能和大容量导入测试用例。
  • 只剩下 3 个空间层（遗憾的是，它们分别是 32,64 和 92GB 的 shapefile 的巨大空间层）用更多信息更新了问题
【解决方案3】：

最后通过三个修复解决了这个问题： 设置 cache_type=none 增加 neostore 低级图引擎的堆大小和 设置 use_memory_mapped_buffers=true 以便由操作系统而不是缓慢的 JVM 完成内存管理

这样，我在空间层中的自定义批量插入速度更快，并且没有任何错误/异常

感谢提供的所有帮助，我想我的回答只是这里提供的所有提示的组合，非常感谢

【讨论】：

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-11-21
    • 2021-07-12
    • 1970-01-01
    • 2014-05-27
    • 1970-01-01
    • 2013-05-30
    • 2011-12-10
    相关资源
    最近更新 更多
    热门标签
    Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode