磁盘、RAM 和其他提示

与任何持久化解决方案一样，性能在很大程度上取决于所使用的持久化介质。通常情况下，存储设备速度越快，内存中能容纳的数据越多，获得的性能就越好。本页面概述了运行 Neo4j 时有关磁盘和内存的性能考量。

存储

在考虑存储解决方案时，有许多性能特征需要注意。性能差异可能达到数量级之巨。通常，将所有数据放入内存中可实现最佳性能。

如果您有多个磁盘或持久化介质，将存储文件和事务日志分布到这些磁盘上可能是一个好主意。将存储文件保存在低寻道时间的磁盘上，对读取操作大有裨益。

在应用程序运行时，请使用 dstat 或 vmstat 等工具来收集信息。如果交换分区（swap）或分页（paging）数值很高，则表明数据库未能完全加载到内存中。在这种情况下，数据库访问可能会出现高延迟。

为实现最佳性能，建议为 Neo4j 提供尽可能多的内存，以避免频繁访问磁盘。

页面缓存（Page cache）

当 Neo4j 启动时，其页面缓存是空的，需要进行预热。页面及其图数据内容是根据查询需求按需加载到内存中的。这可能需要一段时间，对于大型存储尤其如此。经常会出现长时间从驱动器读取大量数据块以及高 IO 等待时间的情况。这在页面缓存指标中会表现为页面错误（page faults）的初始激增。随着查询需要且尚未加载到内存中的页面概率下降，页面错误活动会逐渐减少。

页面缓存预热顺序
在 2026.03 中引入

Neo4j 2026.03 引入了 db.memory.pagecache.warmup.order 设置，用于控制页面缓存预热期间数据库文件的加载顺序。这可以通过优先处理关键文件来优化启动性能。

支持三种排序策略：

  • NONE - 文件按其自然顺序加载（默认）。

  • ALPHABETIC - 文件在加载前按字母顺序排序。

  • PRIORITY - 文件根据重要性加载：首先是 x1 存储，然后是 ID 文件，接着是索引，剩余文件按字母顺序排列。PRIORITY 模式对于确保频繁访问的文件首先加载到缓存中、从而减少启动延迟特别有用。上述文件加载顺序与企业版中提供的 block 存储格式相关。

主动页面缓存预热

Neo4j 企业版具有一项称为主动页面缓存预热（active page cache warmup）的功能，该功能默认通过 db.memory.pagecache.warmup.enable 配置设置启用。

工作原理

它缩短了页面错误的激增时间，并使页面缓存预热更快。这是通过在数据库运行时定期记录存储文件的缓存配置文件（cache profiles）来实现的。这些配置文件包含有关哪些数据在内存中、哪些不在内存中的信息，并存储在 data/databases/mydatabase/profiles 目录中。当 Neo4j 下次重启时，它会查找这些缓存配置文件并加载创建配置文件时已在内存中的相同数据。这些配置文件也会作为在线备份和集群存储复制操作的一部分被复制，并有助于预热加入集群的新数据库。

对于大多数场景，该设置应保持启用状态。然而，当数据库重启后工作负载发生变化时，可以禁用该设置，以避免花费时间获取会被立即逐出的数据。

配置选项

将整个数据库加载到内存中

也可以配置 db.memory.pagecache.warmup.preload 以将整个数据库数据加载到内存中。当数据库存储大小小于页面缓存可用内存时，这非常有用。启用后，它会禁用按配置文件的预热，并在启动时将数据预取到页面缓存中。

将指定文件加载到内存中

您可以使用 db.memory.pagecache.warmup.preload.allowlist 设置来过滤要预取的文件。它接受正则表达式作为匹配文件的值。

示例 1. 仅加载节点和关系

例如，如果您只想加载节点和关系，可以使用正则表达式 .*(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，或者 SSD 性能不足，则可以对检查点过程设置人工 IOPS 限制。db.checkpoint.iops.limit 设置限制了检查点过程允许使用的 IO 带宽。在检查点过程中，每个 IO 为 8 KiB 的写入。例如，600 的 IOPS 限制仅允许检查点过程以大约每秒 5 MiB 的速率写入。另一方面，这会使检查点完成所需的时间变长。检查点之间的时间变长可能导致更多的事务日志数据累积，并可能延长恢复时间。有关检查点与日志修剪之间关系的详细信息，请参阅 检查点和日志修剪 部分。IOPS 限制可以在 运行时更改，从而可以在 IO 使用量和检查点时间之间找到平衡点。