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

Question

我目前正在进行一个项目，我们将 Hibernate 搜索升级到版本 5.9.2（从 3.4.2）。我们在 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" 中，executor 服务以 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();
    }
}
...........

这是属性 renamed/removed 吗？我们可以通过任何其他方式配置 lucene 工作线程池大小吗？我在 Hibernate Search 文档中找不到任何关于删除的提及。我们目前在升级 Hibernate 和 Hibernate Search 后遇到性能下降。

Answer 1

移除thread_pool.size

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

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

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

新设计

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

特别是虽然我认为 Lucene 编写线程应该能够推动比其前身更高的速率，但负责加载主要实体及其所有关系的前几个阶段已经统一：少了一个阶段.

建议

总是尝试运行 MassIndexer 和 Tuning Guide 中描述的黑洞后端，这样你就可以确保瓶颈实际上不是在加载数据而不是写入索引中的数据。

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

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

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

How to configure hibernate search 5.9 worker thread pool size

java

lucene

spring

hibernate

hibernate-search