JoshKorn

I'm at a loss to figure out how to get OWSTIMER to not chew up most of the machine CPU time (it's routinely at 80-90%).

I know about diagnostic logging settings, and I've fixed those, but even after I do that, OWSTIMER still grabs over 80% of the available cycles.

So far, the only way I can make this problem go away is to manually stop and restart the Sharepoint Services Timer and Sharepoint Tracing Service.

Can anyone shed light on this issue

Thanks in advance

Josh



Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

Sorry to revive this long dead thread, but I too have the exact same problem.
And after googling it looks like we are not the only ones, however I have found no other solution than "upgrade your system"...

My SharePoint is running alone on a Xeon 2,33 GHz / 2GB RAM dedicated server, isn't this supposed to be enough

Ludovic





Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

Anyone has an idea why





Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

I've tried disabling all "Timer Jobs" and it "looked" like OWSTimer wasn't taking all CPU anymore. I'm trying to re-enable them one-by-one to see if there's like 1 job which causes trouble...




Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

JoshKorn

One faintly-related area that seemed to help quite a lot was to minimize the amount of logging that Sharepoint did, and also minimize the amount of log files that it keeps.

I forget where I found the article that talks about this (I'll post a link once I find it), but by setting the configuration as it recommended, I was able to turn a tub of molasses into something significantly faster.

Josh





Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

Actually I've already taken care of logs (3 files max, every 30 min, and only criticals alerts). But thanks for your advice anyway.

Just in case, I've tried re-enabling all timer jobs, and I'm back to ~80% (not instantly, but after a while)... so I'll keep on re-enabling one timer job after the other to locate the problem.



EDIT : ok I think I know what you were precisely talking about ; I've found this thread which says to configure events to be logged only if "Warning" and "Unexpected"... we'll see tomorrow if that solved the problem Smile






Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

Okey, I've got some more news... but not good ones...

Having reduced the logs didn't seem to be the problem because lags still exist.

BUT

I have noticed something : my SharePoint server's clock is automatically synch'ed to my DNS/AD/Exchange VirtualPC2004 server whose clock time is always screwed up... (why ). And then, when I've noticed that when SharePoint is logging during a clock synch, it THEN takes all CPU load....

I feel this is the problem because once I manually change the clock back to correct time (ie: after it has started "freezing"), the OWSTimer.exe fall back to 0% CPU instantly.

Here's the only thing logged :

06/06/2007 14:26:57.68 OWSTIMER.EXE (0x0E04) 0x0E34 Windows SharePoint Services Timer 7psa Critical The Execute method of job definition Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition (ID a9539e0e-0ee2-46ee-8604-9afc699b3f7a) threw an exception. More information is included below. Exception from HRESULT: 0x80040D23
06/06/2007 14:26:57.68 OWSTIMER.EXE (0x0E04) 0x0E34 Windows SharePoint Services Timer 72ae Unexpected Exception stack trace: at Microsoft.SharePoint.Search.Administration.MSSITLB.IGatherManagerAdmin3.get_ConfigurationVersion() at Microsoft.SharePoint.Search.Administration.Gatherer.ProvisionGlobalProperties() at Microsoft.SharePoint.Search.Administration.Gatherer.Provision() at Microsoft.SharePoint.Search.Administration.SPSearchServiceInstance.Synchronize(Boolean installGathererApplication) at Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition.Execute(Guid targetInstanceId) at Microsoft.SharePoint.Administration.SPTimerJobInvoke.Invoke(TimerJobExecuteData& data, Int32& result)

Any idea why it is doing this or how to solve the clock synch issue






Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

gpk2005

Has the DST patch been applied on the MOSS servers I guess this could be the reason.




Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

Chris Flesia

I too was having the same problem. I'm running mine in VMware and its clock was wacky too. After seeing your clock synch issue idea, I searched for a way to make it so my VM's clock wouldn't go faster than it should. After changing a few settings, my VM's clock no longer gets ahead of the actual time and OWSTimer no longer consumes all of my CPU.



Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

Actually we are living in a country (French Polynesia) where DST doesn't apply.
But, I've found a workaround here which at first seemed odd because unintuitive, but eventually worked : switching default TimeProvider (time.windows.com) with one of our DC.

Now it clearly seems to solve the whole CPU issue... hope it'll last !





Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

lchungue

Glad this seems to work for you too !






Re: SharePoint - Setup, Upgrade, Administration and Operation Why does OWSTIMER routinely take up 85-90% CPU?

gpk2005

I applied the DST patch but yet the situation is the same. As per the information here, if we dont ask the system clock to Automatically adjust for DST, there will delay in the SharePoint Timer Jobs. I will try out this option and see.
http://mindsharpblogs.com/penny/category/65.aspx/rss

Thanks
Guruprasad