Tuesday, 8 January 2008

OWSTimer Hogging Processor Part 2

It seems there was more...

The fundamental issue on this VM environment turned out not to be the time synch issue in all probablity, but a lack of resources in the environment.

3 Server pools had been set up, dev, test and live. VMWare allocated the resources 33% to each. There were 3 live servers, and one of the servers had been given an exact memory allocation equating to most of the resources available to the server pool.

Of course, if you only ever log into your VMs through RDP then your machine will tell you how much ram the VM image believes to be in its "Hardware". The effect - VMWare Infrastructure client reports that resources are not fully utilised (so no problems) but your VM client reports maximum processor usage (normally OWSTimer is the offender when you notice, or sometimes the mssearch service.

The answer in the case of this environment was simply to remove the server pools, and allow all the servers to contend normally for the resources they required. Server pools are a double edged sword....

1 comment:

  1. Thanks for pointing us in the direction of time synchronization, this led us to investigate along these lines a little further. We found that inside our VMware cluster if we force our MOSS and SQL servers to run on the same physical ESX host all problems immediately ceased. Hope this small piece of information is of value to you, Thanks again for pointing us in the right direction

    ReplyDelete