代码之家  ›  专栏  ›  技术社区  ›  Nullbeans

如何配置Hibernate Search 5.9工作线程池大小

  •  0
  • Nullbeans  · 技术社区  · 8 年前

    我目前正在进行一个项目,我们将hibernate search升级到5.9.2版本(从3.4.2)。我们在lucene 5.5.5和spring boot 1.5中使用hibernate搜索。我们使用的是Hibernate5.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();
        }
    }
    ...........
    

    此属性是否已重命名/删除?我们可以用其他方法配置lucene工作线程池的大小吗?我在hibernate搜索文档中找不到任何关于删除的内容。升级hibernate和hibernate search后,我们当前的性能正在下降。

    1 回复  |  直到 8 年前
        1
  •  2
  •   Sanne    8 年前

    删除线程池大小

    我自己搬走了那处房产,因为它很危险;它被弃用了很长一段时间,后来终于搬走了。由于您正在从3升级到5,不幸的是,您不会看到deprecation警告,因为它们现在也被删除了。

    当拥有 线程池 属性设置为任何高于1的值都有可能对某些写入事件重新排序,因此这是一个错误。

    但我不知道这会导致写性能的显著下降:lucene写后端代码自3.x以来已经发展了很多,现在一个线程能够以更高的速度将更大的更改批推送到索引中,可能会用一个线程使你的IO能力饱和,所以我会 通常地 希望表现更好。

    新设计

    所有这些更改的警告是,显然总体设计有点不同,因此您可能继承的任何优化选项都应该进行检查。

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

    建议

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

    一旦您对数据的加载速度感到满意,通常可以通过使用其他可调参数(如 梅尔吉因子 RAM缓冲区大小 ;如果我错了,你可以:

    • 启用分片,这将线性地提高索引写入速度(只要分片不共享相同的存储瓶颈,但线程也不会有帮助)
    • 向hibernate搜索团队提供一些详细的分析数据,例如,理想情况下,您可以创建一个新的jira并附加一个来自flight recorder的记录。