Index creation (Hibernate Search 5.11) (mass indexer) taking a long time

Hi All,

I have around 2.1 million records that i am trying to creating an index on. I’ve been playing around with tuning (i.e threads and batch size). No matter the setting, after a few hours it settles into 20 documents a second.

I had the threads at 30 (my pool size was 40 min 100 max), but kept getting connection resets / or no JDBC connections. So i reduced it to 10 to stop errors.

public void buildIndex() {
        FullTextEntityManager fullTextEntityManager = Search.getFullTextEntityManager(entityManager);
        try {
                .createIndexer( Interaction.class )
                .batchSizeToLoadObjects( 100 )
                .cacheMode( CacheMode.IGNORE )
                .threadsToLoadObjects( 10 )
                .idFetchSize( 300 )
                .transactionTimeout( 691200 )
                //.progressMonitor( monitor ) //a MassIndexerProgressMonitor implementation
        } catch (InterruptedException e) {
            logger.error("Caught Exception: ", e);

Example speed at start:

2022-02-11 22:55:15.631  INFO 96088 --- [ntifierloader-1] o.h.s.b.i.SimpleIndexingProgressMonitor  : HSEARCH000027: Going to reindex 2135095 entities

2022-02-11 23:02:18.521  INFO 96088 --- [ entityloader-3] o.h.s.b.i.SimpleIndexingProgressMonitor  : HSEARCH000030: 21450 documents indexed in 403867 ms
2022-02-11 23:02:18.522  INFO 96088 --- [ entityloader-3] o.h.s.b.i.SimpleIndexingProgressMonitor  : HSEARCH000031: Indexing speed: 53.111546 documents/second; progress: 1.00%

Then after a few hours:

2022-02-12 09:17:34.491  INFO 96088 --- [ entityloader-5] o.h.s.b.i.SimpleIndexingProgressMonitor  : HSEARCH000030: 851900 documents indexed in 37319836 ms
2022-02-12 09:17:34.491  INFO 96088 --- [ entityloader-5] o.h.s.b.i.SimpleIndexingProgressMonitor  : HSEARCH000031: Indexing speed: 22.827003 documents/second; progress: 39.90%

I did initially test on a smaller data set (same entities etc) of around 100k, i was able to get through that in 10 mins. And that was around 100 documents a second.

Am i missing something here? or can anything be done to speed this up?

Here are the indexed entities (they are pretty big, but only have a few fields), ive not included getters / setters

@NormalizerDef(name = "lowercase", filters = {
	@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
	@TokenFilterDef(factory = LowerCaseFilterFactory.class)
@Table(name = "Interaction")
public class Interaction  {

	private static Logger logger = LoggerFactory.getLogger(Interaction.class);

	private String id;

	private Short status;

	private Short entityTypeId;	

	private String mediaTypeId;

	private String typeId;

	private byte[] allAttributes;

	private Boolean canBeParent;

	private String categoryId;

	private String contactId;

	private Integer creatorAppId;

	private Timestamp endDate;

	private String externalId;

	private Integer intAttribute1;

	private Integer intAttribute2;

	private Integer intAttribute3;

	private Integer intAttribute4;

	private Integer intAttribute5;

	private Boolean isCategoryApproved;

	private Boolean isSpam;

	private String lang;

	private Timestamp modifiedDate;

	private Integer ownerId;

	private String parentId;

	private String queueName;

	private Timestamp startDate;

	private String stoppedReason;

	private String strAttribute1;

	private String strAttribute10;

	private String strAttribute2;

	private String strAttribute3;

	private String strAttribute4;

	private String strAttribute5;

	private String strAttribute6;

	private String strAttribute7;

	private String strAttribute8;

	private String strAttribute9;

	private String structTextMimeType;

	private String structuredText;

	private String subject;

	private Integer subTenantId;

	private String subtypeId;

	private Integer tenantId;
	private String text;

	private String theComment;

	private Integer threadHash;

	private String threadId;

	private Short timeshift;

	private String webSafeEmailStatus;

	@JoinColumn(name = "id", insertable = false, updatable = false)
    private PhoneCall phoneCall;

	@JoinColumn(name = "id", insertable = false, updatable = false)
    private EmailIn emailIn;
	@JoinColumn(name = "ownerId", insertable = false, updatable = false)
    private CfgPerson cfgPerson;
@Table(name = "EmailIn")
public class EmailIn {

	private String id;

	@Field(normalizer = @Normalizer(definition = "lowercase"))
	private String fromAddress;

	private String fromPersonal;

	private String replyToAddress;

	private String toAddresses;

	private String ccAddresses;

	private String bccAddresses;
	private Timestamp sentDate;
	private String mailbox;

	private String whichRuleMatched;

	private String emailOutId;

	@OneToOne(mappedBy = "emailIn")
    private Interaction interaction;
@Table(name = "PhoneCall")
public class PhoneCall {

	private String id;
	private Integer duration;

	private String outcome;

	private String phoneNumber;

	private String tConnectionId;

	@OneToOne(mappedBy = "phoneCall")
    private Interaction interaction;
@Table(name = "cfg_person")
public class CfgPerson {

	private Integer dbid;

	private Integer tenantDbid;

	@Field(normalizer = @Normalizer(definition = "lowercase"))
	private String lastName;

	@Field(normalizer = @Normalizer(definition = "lowercase"))
	private String firstName;

	private String addressLine1;

	private String addressLine2;

	private String addressLine3;
	private String addressLine4;
	private String addressLine5;
	private String office;
	private String home;
	private String mobile;
	private String pager;
	private String fax;
	private String modem;
	private String phonesComment;
	private String birthdate;
	private String comment;
	private String employeeId;
	@Field(normalizer = @Normalizer(definition = "lowercase"))
	private String userName;
	private String password;

	private Integer isAgent;
	private Integer state;
	private Integer csid;
	private Integer tenantCsid;
	private Integer placeDbid;
	private Integer placeCsid;
	private Integer capacityDbid;
	private Integer siteDbid;
	private Integer contractDbid;

	private String saltedString;

	private Integer chPassOnLogin;
	private Integer passUpdating;
	private Integer passHashAlg;

	@OneToMany(mappedBy = "ownerId")
    private Set<Interaction> interaction;

Sorry, on thing i forgot to mention. The smaller dataset was actually in a different DB, same schema. So maybe thats the bottle neck.

The fact that the speed goes down over time is normal. It’s because we’re displaying the overall speed, i.e. total_indexed_count/total_time. Indexing is often orders of magnitude faster for the first few entities, which artificially increases the overall indexing speed for a long time, but after some time the number gets back to the actual value (in your case, 20 docs/s, which is indeed slow).

We probably should move to some rolling average of indexing speed, so that this stat is less confusing; I opened HSEARCH-4483 to address this.

Honestly, the most likely bottleneck is loading data from the database, because that’s where most of the resource-intensive work happens.

The very first thing to check is whether you have database indexes on your foreign key columns, so that association loading is as fast as possible. I’m talking about the foreign keys that are behind the associations Interaction#phoneCall, Interaction#emailIn, Interaction#cfgPerson.

Once that’s solved, if indexing is still slow, then enable SQL logging, have a look at the SQL that Hibernate Search uses to load your entities during mass indexing, and check that the queries execute in a reasonable time; if not, try to tune that, like you would for any other slow SQL query.

For more advice, see this section of the reference documentation and this answer on stackoverflow

If you run out of ideas to tune data loading from the database, and database loading performance seems reasonable to you, you can always try to tune Lucene indexing performance, in particular merging. But that will be slightly more complex, unless you’re already familiar with Lucene.

Thanks for the reply. I just came back to say, that it ended up being resource constraints on the DB side. We increased the compute resources (its in Azure) and the speed it much better.

1 Like

Glad it worked out. Thanks a lot for keeping us updated!

1 Like