locked
microsoft.exchange.search.exsearch.exe running high CPU

    Question

  • Hello,

    I am having a problem on my 2008 R2 mailbox server. The server is only an Exchange 2010 SP1 mailbox role. All rollups applied.

    I have noticed for at least a couple of weeks now, the process microsoft.exchange.search.exsearch.exe is taking all the CPU, or as much as it can. If I end the process, it restarts after about 30 seconds and immediately jumps to 100%. If I reboot the server, as soon as the process starts, it goes to 100%.

    I have done some research, and it's been suggested that a database is unmounted. I can confirm that 3 databases (db 01, Mailbox Database 1275795990, and Public Folder Database 1488256717) are all mounted.

    So I have no idea what else to try. It doesn't seem to be affecting mail flow, but I'm worried it could cause latency for users trying to search their inboxes and folders. Some users have occassionally been getting the popup in Outlook "Outlook is trying to connect to server ...." I'm wondering if these issues are related.

    Please help!

    Monday, January 31, 2011 4:29 PM

Answers

  • I found the solution for this:

    Stop the Microsoft.Exchange Search Indexer Service.

    Delete (or move) the folder under Mailbox\(Database name)\CatalogData-...

    The CatalogData folder holds the index catalog.

    Start the Microsoft.Exchange Search Indexer Service.

    The CPU will stay at around 100% for 15 - 20 minutes while the index catalog rebuilds. A new CatalogData folder is created in your database folder. When this is complete, the CPU should drop down to the normal load.

    Problem solved. The CPU is now steady around 5%.

    • Marked as answer by jayIT8 Monday, February 21, 2011 5:02 PM
    Monday, February 21, 2011 5:02 PM
  • Hi JayIT8,

    Please refer to below about how to reset the index, also the same as exchange 2010:
    http://technet.microsoft.com/en-us/library/aa995966(EXCHG.80).aspx
    You could do that, note to restart the search service will rebuild the index.

    Regards!
    Gavin
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Gavin-Zhang Monday, February 14, 2011 2:53 AM
    Thursday, February 10, 2011 5:19 AM

All replies

  • I was also looking through the Event log. System log looks good. The Application log shows thousands for Performance counter updating errors (anyone know how i can fix those too?).

    But I also found this error too:

    Content Indexing function 'CISearch::EcGetRowsetAndAccessor' received an unusual and unexpected error code from MSSearch.

    Mailbox Database: db 01

    Error Code: 0x8007007e

    Could this be related or at least something I should be concerned about? I only see it logged once, but it was today.

    Monday, January 31, 2011 4:45 PM
  • to test exchange search please follow the article below

    http://technet.microsoft.com/en-us/library/bb123701.aspx


    Dhruv
    Monday, January 31, 2011 5:22 PM
  • I

    I've been having the same issue, and just posted on another forum a few minutes ago, so I'm glad someone else is experiencing it. What is strange, is that I have three mailbox servers and only two are experiencing it. They have the same hardware/software, service packs, rollups, etc. I've tried the stopping the service, deleting the indexes, and starting it again, but that doesn't seem to fix it. I also applied UR2, and that hasn't seemed to fix it. I get tired of seeing the CPU at 80% all day on these machines.

    I'm going to try the steps in Dhruvaraj's post, and see if that helps identify the problem.

     

    Monday, January 31, 2011 5:46 PM
  • Dhruvaraj,

    Here are the results of the tests. I believe Mailbox Database 1275795990 is the default db created when Exch 2010 is installed. And db 01 is the current user mailbox db:

    Get-MailboxDatabase | Format-Table Name,IndexEnabled returned:

    Mailbox Database 1275795990     False

    db 01   True

     

    Get-MailboxDatabaseCopyStatus | Format-Table Identity,ActiveDatabaseCopy,ContentIndexState -Auto returned:

    Mailbox Database 1275795990    Failed

    db 01   Healthy

     

    Test-ExchangeSearch returned:

    Mailbox Database 1275795990    False  Time out for t....

    db 01   False   Time out for t....

     

    So it appears the original default database Mailbox Database 1275795990 has issues? I'm not even sure it exists as a file. Also, the Test-ExchangeSearch failed for both databases, but I can search the production "db 01" database in Outlook, but not OWA. .... odd...

    What do you think based on those results?

    Monday, January 31, 2011 6:17 PM
  • indexing is enabled for the user database, please update the copy with catalogonly parameter and test-exchangesearch with  IndexingTimeoutInSeconds greater than 120 seconds and see if you are able to test sucessfully

    about the first database, if you do not have the files how is it mounted, this is supposed to contain the arbritation mailboxes,


    Dhruv
    Monday, January 31, 2011 7:18 PM
  • When I try to run Update-MailboxDatabaseCopy -Identity "db 01\server" -CatalogOnly

    it returns: Database "db 01\server" has only one copy. This task is supported only for databases that have more than one copy.

    So I can't complete the command. The Test-ExchangeSearch still fails using 120 second timeout.

    Also, I did find the file for Mailbox Database 1275795990. It was in a different location that I expected.

    What next?

    Monday, January 31, 2011 7:52 PM
  • I wanted to bump this because I'm stuck on this issue.

    I don't know what else to do and my CPU is at 100% 24/7.

    Please help!

    Wednesday, February 2, 2011 3:19 PM
  • I had this exact same issue.  Exchange 2010 SP1 and microsoft.exchange.search.exsearch.exe process was chewing up 100% CPU.  I eventually found that my Exchange server has a DNS setting pointed to a server that I had decommissioned a few days before....oops.  Anyway, when I updated the DNS settings and rebooted the server the microsoft.exchange.search.exsearch.exe process stopped chewing up my CPU.
    Friday, February 4, 2011 3:47 PM
  • Hi JayIT8,

    Per you description, the databases seems related with some issue, I would do some tests as below:
    1. run the EXBPA to onfirm more information
    2. use isinteg to fix the database
    3. reseed the the search catalog, some information for you:
    http://technet.microsoft.com/en-us/library/ee633475.aspx
    4. set the mailbox database diagnose log as a high level, confirm which database has the exact issue, and then move all the mailboxes to a new database.

    Regards!
    Gavin 
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Edited by Gavin-Zhang Wednesday, February 9, 2011 1:43 AM
    Monday, February 7, 2011 6:54 AM
  • Unfortunately for me, all of my DNS settings are correct on this mailbox server. There are two DNS servers that point to two DCs which are both GCs.

    Running the Troubleshooting Assistant doesn't show any "problems." It says there are no bottlenecks.

    It does say: %Processor time should always be below 90% except when Content indexing is running. The measured value is at 100%, and content indexing processes account for 49.31% of the total CPU usage. This does not indicate a problem.

    The processor stays at 100% 24/7. I know it says this does not indicate a problem, but if this was normal, I would have read about it by now.

     

    Tuesday, February 8, 2011 10:37 PM
  • I'm wondering if I need to rebuild the indexing catalog on the database. Is this advisable? What affect will it have on the system during the rebuild process?

    Can someone provide me the steps to do this?

    Wednesday, February 9, 2011 2:22 PM
  • Hi JayIT8,

    Please refer to below about how to reset the index, also the same as exchange 2010:
    http://technet.microsoft.com/en-us/library/aa995966(EXCHG.80).aspx
    You could do that, note to restart the search service will rebuild the index.

    Regards!
    Gavin
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Gavin-Zhang Monday, February 14, 2011 2:53 AM
    Thursday, February 10, 2011 5:19 AM
  • I found the solution for this:

    Stop the Microsoft.Exchange Search Indexer Service.

    Delete (or move) the folder under Mailbox\(Database name)\CatalogData-...

    The CatalogData folder holds the index catalog.

    Start the Microsoft.Exchange Search Indexer Service.

    The CPU will stay at around 100% for 15 - 20 minutes while the index catalog rebuilds. A new CatalogData folder is created in your database folder. When this is complete, the CPU should drop down to the normal load.

    Problem solved. The CPU is now steady around 5%.

    • Marked as answer by jayIT8 Monday, February 21, 2011 5:02 PM
    Monday, February 21, 2011 5:02 PM
  • Hi All,

    In my case, i followed JayIT8's reply to delete the contents underneath the Mailbox\(Database name)\CatalogData folder, but after restarting my exchange server, i got a extremely start up time, the server almost hang in "applying computer settings" stage. Anyway, after the computer started correctly, i found everything like before, the microsoft.exchange.search.exsearch.exe process still hold almost 100% CPU resouce, but if i run the following command, i solved this issue:

    net stop msexchangesearch && net start msexchangesearch && sc config msexchangesearch start= demand

    but, another additional affair thing needs to do is that: after the comptuer restart, run the command:

    net start msexchangesearch

    but, up till now, i can't find the root cause for this issue, i may do more research to solve this issue,

    Thanks,


    Best regards,

    Devin Zhang
    Partner Online Technical Community
    -----------------------------------------------------------------------------------------
    We hope you get value from our new forums platform! Tell us what you think:
    http://social.microsoft.com/Forums/en-US/partnerfdbk/threads
    ------------------------------------------------------------------------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.

    POTC support provides service from Monday to Friday (your local business hours). Thanks!
    Saturday, November 5, 2011 6:48 AM
  • Thank you jayIT8.

    The indexer service had been running at around 50% CPU utilization for a few days (and this is a small site).  Now, CPU Utilization for the server is less than 5%.


    • Edited by CJADuva Saturday, November 12, 2011 5:48 PM
    Saturday, November 12, 2011 5:47 PM
  • Nice one.

     

     

    CPU is now back to normal.

     

     

    Big Thanks.

     

    Michael


    mwalshe
    Friday, January 20, 2012 8:57 PM
  • Is the cause for this known? It's good to have a fix but it looks like this kind of issue can be recurring. I can't find anything on the Technet site that points to the cause being identified or fixed in any rollups/patches.

    This happened to my organisations exchange box today and would like to prevent any future events. Anyone know if it has been resolved already or is there only this?


    • Edited by snale Wednesday, February 8, 2012 2:50 AM
    Wednesday, February 8, 2012 2:42 AM
  • One another possible option would be to "finetune" the indexer. For example you might wish to

    - Disable some File formats indexed

    - Change the maximum size file that can be indexed

    - Adjust the Processor Affinity Percentage

    - MaxAttachmentDepth

    - ...

    You can find here more infos about the possible options.

    • Proposed as answer by Bastian_W Wednesday, November 9, 2016 12:43 PM
    Wednesday, November 9, 2016 12:43 PM