Performance Neo4j 1.9.4（REST服务器，CYPHER）性能问题

我在24核24Gb ram（centos）机器上安装了Neo4j 1.9.4，对于大多数查询，CPU使用率峰值达到200%，只有少量并发请求

域：

neostore.nodestore.db.mapped_memory=1280M
wrapper.java.maxmemory=8192

某种社交应用程序，其中少数类型的节点（配置文件）具有3-30个文本/数组属性，36个关系类型至少具有3个属性。大多数节点目前有约300-500个关系

当前数据集示意图（从控制台）：

这真的很小。 大多数查询看起来像这样（或多或少带有..MATCH..语句，很少有查询具有可变长度关系，但通常是快速的）：

注意：我已经尝试过配置，所有与内存相关的参数都很高，但不起作用（根本没有变化）

问题：

neostore.nodestore.db.mapped_memory=1280M
wrapper.java.maxmemory=8192

去哪里挖掘？配置计划？询问？我做错了什么

---

如果需要更多信息（日志、配置），请询问；）

同一查询的后续调用要快得多的原因很容易用缓存的使用来解释。一种常见的策略是在启动时运行缓存预热查询，例如

start n=node(*) match n--m return count(n)

24核上200%的CPU使用率意味着机器非常懒惰，因为只有2个核繁忙。当一个查询正在进行时，CPU在运行时达到100%是正常的

上面的Cypher语句使用可选匹配（在第2个match子句中）。这些可选的匹配被认为是潜在的慢匹配。如果将此设置为非可选匹配，请检查运行时是否更改

<>当返回一个较大的结果集时，考虑传输响应是由网络速度驱动的。在案例中考虑使用流式，参见

您还应该将

wrapper.java.minmemory

设置为与

wrapper.java.maxmemory

相同的值

---

对于较小的图形，另一种方法是关闭MMIO缓存，并使用

cache\u type=strong

将完整的数据集保留在对象缓存中。在这种情况下，您可能需要增加

wrapper.java.minmemory

和

wrapper.java.maxmemory

是否在控制台中使用查询前面的PROFILE关键字运行查询？它会给出一些关于查询是如何运行的信息。在查询时100%地执行，看起来是潜在的瓶颈（有许多并发请求）。我已经尝试设置min=max=VERY_HIGH_值并更改缓存类型，但没有任何更改。如何在不使用可选匹配的情况下获得相同的结果集？

start n=node(*) match n--m return count(n)