磁盘、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 使用率和检查点时间之间的正确平衡。