Runaway indexing on Build 9056

Problem reported by Douglas Foster - 10/25/2024 at 8:43 AM

Being Fixed

System has experienced overutilized CPU since upgrading Monday night from build 8888. Support said a file restructure was expected and that it would create indexing overhead for awhile. System is still maxed out and I finally checked the indexing log. My own account has been reindexed 29 time today. Log set to detailed, but no errors visible. Some entries finish with Reindex: True for no apparent reason, but I see some entries where the user is immediately reindexed even when the result is Reindex: False

So far today: 7014 indexing operations done, 6716 ended with reindex false, 298 ended with reindex True. We have a little under 2000 user accounts, plus some aliases and maililng lists.

7 Replies

Reply to Thread

Richard Laliberte Replied

10/25/2024 at 8:52 AM

We upgraded from 8993 on Saturday, and didn't notice any CPU issues. Probably should have made a smaller jump as there have been a LOT of updates since 8088. The current "recommended" upgrade is 8930 for stability of all services including MAPI. Hopefully things are things get resolved for you soon!

Douglas Foster Replied

10/25/2024 at 9:30 AM

Correction: prior build was custom build 8888. I should not have worked from memory

Douglas Foster Replied

10/25/2024 at 1:24 PM

Reduced indexing threads to reduce CPU load and increased indexing queue wait time to reduce the frequency that a mailbox is re-indexed. Seems to be helping.

Douglas Foster Replied

10/31/2024 at 1:05 PM

Update: My system was minimally configured, but after adding CPU, performance was still poor. Rather than roll back, I decided to collect data. With help from a JetBrains snapshot, development has confirmed a problem and is working on a fix.

As an aside, I have had no complaints about Outlook misbehavior in this version. That may be because we do not have character set issues, because we are a U.S. company with a regional market.

Zach Sylvester Replied

10/31/2024 at 1:56 PM

Employee Post

Hey Doug,

Thanks for working with us to fix this issue and sharing your experiences.

Kind Regards,

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com

Rod Strumbel Replied

11/1/2024 at 7:53 AM

We always use the rule to set the number of Indexing threads to the number of logical processors in the machine - 2.

That has worked well for us thru version 8451 that we remain on

We have 6 logical processors, so we have 4 indexing threads.

Don't remember where we got that info originally but it has worked well for us.

Douglas Foster Replied

11/1/2024 at 8:10 AM

CPU count minus 2 is the rule of thumb suggested in the help system.

To give you a sense of the problem, we have been running with only 2 CPUs. My VMWare admin had reduced CPUs on all guest systems to 2, as a VMWare tuning move. Arguably, that left us us underpowered, but it has been working well for a long time, even though index threads was left at 3 and queue wait time was only 5 seconds. (Documentation recommends queue wait time of 60 seconds.)

After the update, performance was terrible, so I increased CPUs to 4, reduced index threads to the minimum of 1, and increased queue wait time to 5 minutes. Performance is still bad, but I have decided that it is bearable.

Fortunately, JetBrains helped them find a problem. You can see why I am waiting, with baited breath, for the next release.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text