OWSTimer Hogging Max Processor Time in VMWare

This issue isn't exclusive to VMWare, but is much easier to come across. You may notice your MOSS server being completely unresponsive for serveral minutes at a time. On investigation you find that OWSTimer is taking up 80%-100% processor utilisation. I have particularly found this occuring on VMWare MOSS installations, and often occurs straight after you restart a VM that has been off for a significant amount of time.

The issue here is clock time synch. If the SQL Server/SharePoint server do not agree then OWSTimer gets itself in a right tizz and maxes the processor. In a VM environment this might look particularly weird - as your VM Host may be reporting plenty of resources available.

To resolve this (in WMWare)

To resolve this do the following:

• Stop and disable the OWSTimer and Windows SharePoint Services Tracing services
• Install VMWare Tools if not already installed on the SQL and SP boxes
• Right click on the VMWare System Tray icon and tick the "Time Synchronisation between the virtual machine and the console operating system
• Ensure your VM host synchronises time from your internal time synch service (ie in synch with the AD controller)
• Verify that all servers are time synched
• restart OWSTimer and Tracing services

Why does this happen so much in VMWare?

Well, VMWare has issues when the CPU goes into powersaving modes, meaning that the clocks don't correctly calculate time (eg the VM image thinks it is running at 2.4Ghz, but is actually at 1GHz), therefore gets out of synch easily. The same effect seems to occur when you power up a VM image that has been left for months.