控制每个 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 条带（即文件描述符）。可以将其设置为 0，以使每个映射文件仅使用一个文件描述符。设置为 1 会打开 2 个描述符，2 会打开 4 个，3 打开 8 个，以此类推。需要注意的是，将 channelStripePower=0 设为 0 可能会导致性能下降，这也是它不是默认值的原因。降低此设置可能会影响性能，尤其是在 Windows 上，但在例如 macOS 上可能还能接受。由于每种硬件不同，最好尝试不同的数值，以找出适合特定硬件配置的参数。
参考文献
此页面有帮助吗？