控制每个 Lucene 索引创建的文件句柄数量
在较新的 Neo4j 版本（3.4 及更高版本）中，与旧版本相比，Neo4j 打开的文件句柄数量似乎有所增加。原生索引需要每个索引常数个文件句柄，并且此数量会根据系统上可用的 CPU 核心数量进行扩展。
这是因为某些索引实现（例如 lucene+native-1.0）使用更多文件描述符，并且对于大量索引（1000+ 超过平均水平），达到 60K 打开文件描述符限制的可能性变大。这是因为为了优化 I/O 性能，我们为所有文件打开了多个通道。lucene+native 组合为两个索引引擎创建文件，以准备处理两者，即使其中一个未使用。虽然消耗的磁盘空间可以忽略不计，但每个索引仍然会使用几个额外的文件描述符。目前，无法关闭此功能，但将来纯原生索引选项可能会解决此问题。
基于 Lucene 的索引需要每个索引数量的文件句柄，这些文件句柄的数量会根据与索引交互的打开事务的数量进行扩展。例如，在 72 个 CPU 核心和 100 个原生索引的情况下，每个索引的文件句柄数量将达到 64 个。首先确定当前架构索引的数量（从 CALL db.indexes() 返回的行数）以及当前的默认索引提供程序可能很有用。这由 neo4j.conf 中的 dbms.index.default_schema_provider 值设置，例如 lucene+native-1.0 或 native-btree-1.0。
文件描述符的数量在高负载期间很可能会激增，因此即使数据库设法启动，它仍然可能因该限制在运行时失败，因此建议在此处保留一定的余量。这是因为索引在事务执行期间创建了许多较小的文件，然后在后台线程中合并为单个大文件。通常，此合并速度快于事务速率，但在这些文件合并之前仍然存在一些延迟，并且这会暂时增加打开的文件数量。
但是，此打开文件数量增加的影响高度依赖于操作系统和硬件。如果需要，可以使用一个未公开的功能标志调整条带化因子，例如：
-Dorg.neo4j.io.pagecache.implSingleFilePageSwapper.channelStripePower=2
默认值根据可用 CPU 核心的数量计算得出，四舍五入到上面列出的最接近的数字。上述参数的整数值是 2 的指数。因此，如果 channelStripePower 为 5，则将获得 2^5 = 32 个条带，即每个映射文件的 32 个文件描述符。可以将其设置为 0 以使每个映射文件只有一个文件描述符。将其设置为 1 将打开 2 个文件描述符，2 将打开 4 个，3 打开 8 个，依此类推。请注意，设置 channelStripePower=0 可能会影响性能，这就是它不是默认值的原因。降低此设置可能会影响性能，尤其是在 Windows 上，但在例如 macOS 上，您可能可以降低它。由于每个硬件都不同，因此最好尝试使用各种值来查看哪种值适合给定的硬件设置。
参考
此页面是否有帮助？