How To Fix OWSTimer.exe taking 100% CPU Issue
Problem
OWSTimer.exe taking 100% CPU and/or creating Gigabyte sized log files.
Solution
Below are the steps I used to troubleshoot the client’s environment with the actual screenshots. In the end I believe that a simple stsadm –o execadmnsvcjobs did the trick.
Step 1- Check the logfiles, they are too big to open.
Step 2 – Are we out of drive space?
Step 3 – With permission from the client, stop “Windows SharePoint Services Timer”
Step 3 – Also stop the “Windows SharePoint Services Tracing” services
Step 4 – Review the log. We clearly have timer job issues
Step 5 – Review the event log. Hmm, note how the time changed? Client confirmed that they had a time issue with the server a few weeks back. Looks like we had daylight savings time kick in unexpectedly this morning.
Step 6 – Review the timer jobs. Nothing significant to see
Step 7 – Let’s execute any pending jobs
Step 8 – Before we restart let’s turn off tracing so that we don’t keep filling up the log files (note that we do turn tracing back on later).
Step 9 – Restart the “Windows SharePoint Services Timer” and “Windows SharePoint Services Tracing” services
Step 10 – Re-run stsadm –o execadmsvcjobs
Step 11 – Check the timer service, CPU looks good!
Step 12 – Re-enable tracing
Explanation/Theory
Time change caused timer job to trigger because it thought it was the predecessor of a timer job already in the stack. Of course 2 timer jobs most likely tried to communicate or attach to the same object causing the server to spin into a loop. Large logfiles was simply a side effect (and the logs were behaving properly).
Posted on August 13, 2012, in High CPU, OWSTimer.exe taking 100% CPU. Bookmark the permalink. Leave a comment.
Leave a comment
Comments 0