磁盘、RAM 和其他提示
与任何持久化解决方案一样，性能很大程度上取决于所使用的持久化介质。一般来说，存储速度越快，RAM 中能容纳的数据越多，您将获得的性能就越好。本页概述了运行 Neo4j 时磁盘和 RAM 的性能考量。
存储
您的存储解决方案需要考虑许多性能特征。性能差异可能达到数量级。通常，将所有数据放入 RAM 中可实现最大性能。
如果您有多个磁盘或持久化介质可用，将存储文件和事务日志分散到这些磁盘上可能是一个好主意。将存储文件保存在寻道时间低的磁盘上可以大大提高读取操作的性能。
在应用程序运行时，使用 dstat 或 vmstat 等工具收集信息。如果交换或分页数字很高，这表明数据库未能完全适应内存。在这种情况下，数据库访问可能会有很高的延迟。
|
为了达到最大性能，建议为 Neo4j 提供尽可能多的 RAM，以避免频繁访问磁盘。 |
页面缓存
当 Neo4j 启动时，其页面缓存是空的，需要预热。页面及其图数据内容会根据查询需求按需加载到内存中。这可能需要一段时间，特别是对于大型存储。经常会看到长时间内从驱动器读取大量块以及高 IO 等待时间。这将在页面缓存指标中表现为页面错误最初的急剧增加。页面错误急剧增加之后是页面错误活动的逐渐减少，因为查询需要尚未在内存中的页面的可能性会降低。
活动页面缓存预热
Neo4j 企业版有一个名为活动页面缓存预热的功能，默认通过 db.memory.pagecache.warmup.enable 配置设置启用。
工作原理
它缩短了页面错误峰值，使页面缓存更快预热。这是通过在数据库运行时定期记录存储文件的缓存配置文件来实现的。这些配置文件包含关于哪些数据在内存中、哪些数据不在内存中的信息，并存储在 data/databases/mydatabase/profiles 目录中。下次 Neo4j 重新启动时，它会查找这些缓存配置文件，并加载创建配置文件时在内存中的相同数据。这些配置文件也会作为在线备份和集群存储复制操作的一部分被复制，并帮助预热加入集群的新数据库。
在大多数情况下，该设置应保持启用。但是，当数据库重启后工作负载发生变化时，可以禁用该设置，以避免花费时间获取将被直接逐出的数据。
配置选项
- 将整个数据库加载到内存中
-
也可以配置
db.memory.pagecache.warmup.preload以将整个数据库数据加载到内存中。当数据库存储大小小于页面缓存可用内存时，此功能很有用。启用后，它会禁用按配置文件预热，并在启动时预取数据到页面缓存。 - 将指定文件加载到内存中
-
您希望预取的文件可以使用
db.memory.pagecache.warmup.preload.allowlist设置进行过滤。它接受一个正则表达式作为值来匹配文件。
例如，如果您只想加载节点和关系，可以使用正则表达式 .*(node|relationship).* 来匹配存储文件的名称。活动页面缓存预热将预取以下文件的内容
neostore.nodestore.db
neostore.nodestore.db.id
neostore.nodestore.db.labels
neostore.nodestore.db.labels.id
neostore.relationshipgroupstore.db
neostore.relationshipgroupstore.db.id
neostore.relationshipstore.db
neostore.relationshipstore.db.id
neostore.relationshiptypestore.db
neostore.relationshiptypestore.db.id
neostore.relationshiptypestore.db.names
Neostore.relationshiptypestore.db.names.id并可以使用 Unix grep 进行验证
ls neo4j/ | grep -E '.*(node|relationship).*'- 配置页面缓存的配置文件频率
-
配置文件频率是重新生成配置文件的速率。越频繁意味着越准确。配置文件包含当前加载到内存中的文件部分的有关信息。默认情况下，它设置为
db.memory.pagecache.warmup.profile.interval=1m。生成这些配置文件需要一些时间，因此1m是一个不错的间隔。如果工作负载非常稳定，则配置文件不会发生太大变化。相应地，如果工作负载经常变化，则配置文件也因此经常变得过时。
检查点 IOPS 限制
Neo4j 在后台作为其检查点过程的一部分刷新其页面缓存。这会表现为写入 IO 活动增加的一段时间。如果数据库正在处理写入密集型工作负载，检查点会通过减少可用于查询处理的 IO 带宽来降低数据库速度。在能够处理大量随机 IO 的快速 SSD 上运行数据库可以显著减少此问题。如果您的环境中没有快速 SSD，或者其不足，则可以对检查点过程设置人工 IOPS 限制。db.checkpoint.iops.limit 限制了检查点过程被允许使用的 IO 带宽。在检查点过程中，每次 IO 都是一次 8 KiB 的写入。例如，600 的 IOPS 限制将只允许检查点过程以大约每秒 5 MiB 的速率写入。另一方面，这会使检查点需要更长时间才能完成。检查点之间的时间间隔越长，可能导致更多的事务日志数据累积，并可能延长恢复时间。有关检查点和日志修剪之间关系的更多详细信息，请参阅检查点和日志修剪部分。IOPS 限制可以在运行时更改，从而可以对其进行调整，直到您在 IO 使用和检查点时间之间达到正确的平衡。