本文档列出了一些在计划在同一物理主机上托管多个 Neo4j 实例时需要考虑的事项。

允许使用多个实例，尽管这在实际应用中并不常见。作为规划的起点，理想情况下，应监控每个计划共同托管的 Neo4j 实例在生产环境中 1-2 周内的以下指标：

然后我们需要考虑以下 Neo4j 特定的要求：

在估算/分析完上述指标后，我们可以考虑预期的增长，并判断主机是否能够支持额外的实例（也需要为这些实例估算上述指标），然后才能继续添加更多实例。

让我们以一台具有以下规格的示例机器为例：

以及以下为该机器上已运行的单个 Neo4j 实例设置的示例 Neo4j 参数：

以下是上述单个实例在 6 个月期间的示例 CPU 和内存配置文件：

我们可以看到 CPU 偶尔会达到 30% 的峰值，如果要向主机添加第二个实例，这似乎相当低。

我们可以看到内存使用率经常达到 90% 以上的峰值，有时也达到 50%。

假设在我们的示例中，Neo4j 是唯一的生产应用程序（也是主要使用内存的应用程序），我们需要查看内存使用率达到 50% 和 90% 以上时执行的事务，并加上第二个实例的预期工作负载，从而了解机器所需的 RAM 量。

理想情况下，希望尽可能多地将数据库存储在页面缓存中（以最大程度地减少磁盘命中），同时考虑存储大小、索引和预期的增长。一个经验法则是存储大小 + 预期增长 + 10%。因此，对于一个 12GB 的存储，我们预计它在明年会翻倍，那么我们理想情况下会分配 12GB + 12GB + 1.2GB = 25.2GB。同样，这在很大程度上取决于预期的增长。在大多数情况下，8GB-12GB 是堆的一个不错的默认值，但这最终取决于执行的事务类型。

假设上述情况，每个实例需要 25.2GB（页面缓存） + 12GB（堆） + 3GB（操作系统） = 大约 40GB 的 RAM。由于我们假设主机上有 200GB，这应该足够了，但我们在分析时真正需要查看的是每个实例在生产环境中 1-2 周内的峰值内存使用率。

同样重要的是，假设实例 1 的峰值 CPU 使用率从不超过 X%，而实例 2 从不超过 Y%，并且 X+Y（峰值）始终小于总 CPU 的 90%，那么在这种情况下，在该机器上托管第二个实例可能可以正常工作。

关于 CPU 的另一个重要考虑因素是，总 CPU 可以同时处理多少个线程，以及 CPU 时钟频率是多少。据说超线程核心可以处理两倍的线程数（尽管在实践中，它们只是更有效地利用线程的等待时间来处理其他线程）。因此，也许最好假设最大并发线程执行数等于核心数，在本例中为 12。读写查询提交事务的方式以及线程处理能力（CPU 的时钟速率）将决定每个 Neo4j 实例在峰值时使用 CPU 的百分比。这最好通过随时间的实际分析来估算。

还要考虑每个实例随时间的存储大小和事务日志增长，以避免磁盘空间不足。每个实例的峰值预期增长总和永远不应该超过可用的磁盘空间（这是一个关于事务日志增长和轮换的良好参考：https://neo4j.ac.cn/docs/operations-manual/current/configuration/transaction-logs/）。

最后，配置多个实例时，需要注意端口分配、可用性和冲突，特别是其他 Neo4j 实例使用的端口。如果要设置多个实例进行集群，则必须在每个成员的配置中正确配置集群成员之间通过端口/IP 的通信。