iccaveman
asked on
Windows Search Committing Unusually High Number of Writes
We’ve noticed on our Terminal Server that the Windows Search service is periodically writing large amounts of data (sustained 600,000-1,000,000 B/sec). This was first noticed when our ShadowProtect backups began generating 2-5GB incremental files. We run them every 15 minutes and this is much larger than our typical backup. We tracked the problem down to Windows Search.
This was noticed after rebooting the server. We restarted the WSearch service and things seemed to calm down for a while. Within a couple of days the problem reappeared. Since then we rebuilt the search index and configured to only index Outlook. Again, it seemed to run fine for a couple of days and then we noticed the large incremental backups caused by WSearch.
Our Terminal Server is Server 2012 R2 which is virtualized on an ESXi host machine. We had Widows Search/Indexing up and running without issue long before this problem appeared.
This was noticed after rebooting the server. We restarted the WSearch service and things seemed to calm down for a while. Within a couple of days the problem reappeared. Since then we rebuilt the search index and configured to only index Outlook. Again, it seemed to run fine for a couple of days and then we noticed the large incremental backups caused by WSearch.
Our Terminal Server is Server 2012 R2 which is virtualized on an ESXi host machine. We had Widows Search/Indexing up and running without issue long before this problem appeared.
ASKER
Thank you. I'll take a look at that today and report back. I had not considered what the service was reading so I appreciate your input.
Since ResMon does real-time monitoring, you might want to use SysInternals ProcMon instead to record file actions by the Windows Search processes over a period of time. However, this can create a lot of logging if not used carefully ;-). In particular make sure the tick the "Drop Filtered Events" in the Filter menu, otherwise ProcMon stores everything happening, and not what you filter for, consumimg a lot of memory.
iccaveman, do you have any feedback for us?
ASKER
Robocat,
I did as you suggested but all of the reads seemed to be on ebd.log or the temp version of the log. We ended up creating a new drive that isn't backed up and just relocated the index there.
Qlemo,
I'm sorry that I didn't notice this before we moved the index. Thank you for the suggestion. If this comes up again I'll give that a try.
I appreciate both of your responses.
I did as you suggested but all of the reads seemed to be on ebd.log or the temp version of the log. We ended up creating a new drive that isn't backed up and just relocated the index there.
Qlemo,
I'm sorry that I didn't notice this before we moved the index. Thank you for the suggestion. If this comes up again I'll give that a try.
I appreciate both of your responses.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Under disk you can select the process that you want to monitor. Below click open the pane "disk activity" and you will see the files it is reading and writing. Look at the files it is reading.
Look if the search indexer is taking a long time reading/revisiting certain files. This might be an indication there's something going on with that file.
Hopefully this will give you a clue to investigate further.