Webio,

There are a couple of items that I will explain from your post.  The first thing that I noticed is the Index Segment Count.  By default, this setting is configured for 20.  In SmarterMail 16 and earlier versions, we were using an older version of Lucene and this setting worked.  In the latest versions we have upgrade Lucene indexer to the latest version and made significant optimizations throughout the product.  We are going to be increasing that default number for new installs to somewhere between 1000-2000.  This will positively impact your CPU by increasing that number without negatively impacting indexing.  Second, at 6:37 the log states that it found 53 deletes and 2501 items to index.  By default, we chunk indexing into 2500 items per "loop".  After it has committed that round of indexing it will then index the next 2500, etc.  At 6:38 the log states there are xxx number of unindexed items remaining.  Zero items are left to index and the user is removed from the queue.  I agree that it can be misleading with the quantity and percentage shown.  At first glance you can expect that number to increase instead of decrease overtime to when you have 100% indexed.  I will discuss this with the team and see about changing it to lessen confusion.

I hope this helps!

Ok but can I do something now to speed things up?

I can modify this values:

    "indexing_segment_file_count_before_optimization": 20,
    "indexing_items_before_garbage_collection": 5000,
    "indexing_items_per_pass": 2500,
    "indexing_max_threads": 1,
    "indexing_deleted_items_before_optimization": 1000,
    "indexing_seconds_in_queue_before_index": 120,

from settings file. Also is this normal that I still don't see any difference in search results? IMHO if indexing is telling that user is indexed then searching should work correctly right (I still see only messages from 2013 when looking for "DHL" search phrase where I had many DHL emails recently).

"indexing_segment_file_count_before_optimization": 20
Set this to atleast 500.

Also if you just recently moved to 17, you need to reindex all the user's on your box. If you set your threads to 1, keep an eye on your indexing queue, it might fill up and user's waiting for an index will not get indexed.

Currently I have threads set to 1. It looks like this settin has been inherited from v15->v16->v17. I've changed indexing params to ones from other server which has fresh configuration but I've changed indexing threads

My current Mailbox Indexing in Troubleshooting section is showing almost 5k mailboxes. Interesting thing is that when I open indexing status I see also Completed mailboxes. Should this table just show mailboxes which are or will be indexed?

EDIT: So after night Mailbox Indexing number is 2.7k. It's hard to tell how many are being indexed or waiting in queue since there are a lot of positions with Completed status.