Troubleshooting index update job issues in Sitecore

Having seen many question on the Sitecore Stack Exchange related to index update job issues, I’ve decided to write a blog post on how to identify a root cause of those issues and fix them. For example, it can happen that an index is updated too often or not often enough.

  1. Verify what index update strategy is used for the index and change it if deem necessary.
    You can search for `index id=”index_name”` on `/sitecore/admin/showconfig.aspx` page, `strategies` node. And then check the details about the update strategy on this Sitecore Documentation page and very that it is the most suitable option for the index. For example, it can be the case that Synchronous strategy is used for one of the indexes, which can be degrade system performance in some cases, when a better alternative can be IntervalAsyncronous strategy.
  2. Verify that the interval parameter is set to a value that will not cause unnecessarily frequent updates, and adjust it to fit your needs.
    <intervalAsyncCore type="Sitecore.ContentSearch.Maintenance.Strategies.IntervalAsynchronousStrategy, Sitecore.ContentSearch">
        <param desc="database">core
        <param desc="interval">00:01:00
  3. Verify that this index update strategy is not combined with other strategies that it is not compatible with. For more information about this and other index update strategies, please refer to this Sitecore documentation page.
  4. The next step can be to change log level for Crawling Log to DEBUG (only for a short period of time while troubleshooting). The values is stored in Sitecore.ContentSearch.config config file.
    <logger name="Sitecore.Diagnostics.Crawling" additivity="false">
        <level value="DEBUG"/>
        <appender-ref ref="CrawlingLogFileAppender"/>

    And verify Crawling.log.txt log files for more information on the issue why the index is updated so frequently. If there is an issue, it will be logged. (e.g. EventQueue, Solr connectivity, etc.)

  5. Verify EventQueue table in the corresponding database. It is possible that EventQueue table gets flooded with lots of events. Two admin pages can be used to see details on running, queued and finished jobs and EventQueue statistics:
    /sitecore/admin/Jobs.aspx and `/sitecore/admin/EventQueueStats.aspx`.
    If the aforementioned two pages will not provide enough info, you can run this SQL query on the EventQueue table in the corresponding database for more details, it will show events for updating the index:

    SELECT TOP (10000) [Id]
      FROM [db_Name].[dbo].[EventQueue]
      WHERE InstanceData = '{"FullRebuild":false,"IndexName":"index_name"}'

    On Jobs.aspx page, verify if Index_Update_IndexName=index_name job is queued many times in a short period of time.
    For more information, please refer to this KnowledgeBase article.

Why the log file shows that zero units were processed during index update job?

Quite often you can see that all index update jobs in the logs show that zero units were processed:

ManagedPoolThread #0 22:28:02 INFO  Job started: Index_Update_IndexName=sitecore_core_index

ManagedPoolThread #0 22:28:03 INFO  Job ended: Index_Update_IndexName=sitecore_core_index (units processed: )

INFO-level log records for index update job will only be shown in log.txt files when an index was actually updated. If the update strategy was executed and the EvenQueue is empty, it will only add DEBUG-level log record to Crawling.log.txt file, without adding an INFO-level log records:

33056 21:42:02 DEBUG [Index=sitecore_core_index] IntervalAsynchronousStrategy executing.
33056 21:42:02 DEBUG [Index=sitecore_core_index] Event Queue is empty. Incremental update returns

That means that by default an INFO-level log record for index update job should always contain a certain number of processed units, greater than zero. Therefore, in the log file chunk you have provided, instead of showing zero processed units, it should have displayed some other number greater than zero.

Sitecore Support has registered this as a bug. Unfortunately, there is no easy way to fix this and display the correct number of items. To track the future status of this bug report, please use the reference number 95080.

Useful links:
1. The Knowledge Base article

2. Discussion on SSE

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s