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

虽然多个实例是被允许的，但在实际部署中并不常见。作为规划的起点，理想情况下，应为计划在同一主机上托管的每个 Neo4j 实例监控以下指标（例如持续 1-2 周的生产环境数据）：

然后，我们需要考虑以下 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 的内存。既然我们假设主机上有 200GB 内存，这应该足够了。但我们在分析时真正需要看到的是，每个实例在生产环境中（例如 1-2 周内）的内存峰值使用情况。

同样重要的是，假设实例 1 的 CPU 峰值利用率从未超过 X%，实例 2 的 CPU 峰值利用率从未超过 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 进行的通信。