java - 如何配置hibernate search 5.9工作线程池大小

Question

我目前正在开发一个项目，我们将 Hibernate 搜索升级到版本 5.9.2(从 3.4.2)。我们将 hibernate 搜索与 Lucene 5.5.5 和 Spring boot 1.5 结合使用。我们使用的是 hibernate 版本 5.2.17。

在实体管理器配置 JPA 属性中设置以下属性:

properties.put("hibernate.search.default.worker.thread_pool.size", "5");

但是，这个属性似乎没有任何作用。在调试过程中，我注意到在 Hibernate Search 的“LazyExecutorHolder”中，执行程序服务以 null 启动，并以线程池大小为 1 进行初始化。以下是 hibernate search 代码中的代码片段:

package org.hibernate.search.backend.impl.lucene;
final class LazyExecutorHolder {

/**
 * Lazily initialized; state change protected by executorStateWriteLock
 */

private ExecutorService asyncIndexingExecutor;

public void submitTask(LuceneBackendQueueTask task) {
    executorStateReadLock.lock();
    try {
        final ExecutorService executor = asyncIndexingExecutor;
        if ( executor != null ) {
            executor.submit( task );
            return; // !
        }
    }
    finally {
        executorStateReadLock.unlock();
    }
    //If not returned yet, means the executor wasn't available;
    //Needs to be started within the exclusive lock.
    executorStateWriteLock.lock();
    try {
        ExecutorService executor = asyncIndexingExecutor;
        if ( executor == null ) {
            executor = Executors.newFixedThreadPool( 1, threadNamePrefix, maxQueueLength );
            this.asyncIndexingExecutor = executor;
        }
        executor.submit( task );
    }
    finally {
        executorStateWriteLock.unlock();
    }
}
...........

此属性是否已重命名/删除？我们可以通过其他方式配置 lucene 工作线程池大小吗？我在 Hibernate Search 文档中找不到任何有关删除的内容。目前，在升级 Hibernate 和 Hibernate Search 后，我们遇到了性能下降的问题。

Answer 1

删除 thread_pool.size

我自己删除了该属性(property)，因为它很危险；它已被弃用很长一段时间，然后最终被删除。不幸的是，由于您要从 3 升级到 5，因此您不会看到弃用警告，因为它们现在也已被删除。

当thread_pool属性大于1时，某些写入事件可能会被重新排序，因此这是一个错误。

但是我不知道由此导致的写入性能显着下降:自 3.x 以来，Lucene 写入后端代码已经发展了很多，现在单个线程能够将更批量的更改推送到索引更高的速率，可能会使单线程的 IO 能力饱和，因此我通常期望性能会更好。

新设计

所有这些更改的警告是，显然整体设计有很大不同，因此您可能继承的任何调整选项都应该进行审查。

特别是，虽然我相信 Lucene 写入线程应该能够比其前身插入更高的速率，但负责加载主要实体及其所有关系的前几个阶段已经统一:少了一个阶段。

建议

始终尝试使用黑洞后端运行 MassIndexer，如 Tuning Guide 中所述。这样您就可以确保瓶颈实际上并不在于加载数据，而不是在索引中写入数据。

一旦您对数据加载速度感到满意，通常可以通过使用其他可调参数(例如 merge_factor 和 ram_buffer_size)来使索引写入速度足够接近;如果我错了，你可以:

• 启用分片，这将线性提高索引写入速度(只要分片不共享相同的存储瓶颈 - 但线程也无济于事)
• 联系 Hibernate Search 团队并提供一些详细的分析数据，例如理想情况下，您可以创建一个新的 JIRA 并附加飞行记录器中的记录。